Nikita Popov

> I'm not sure what's the best way forward. I could see us accepting `null -> (ptr)0` as a valid refinement (worst case you add provenance to the pointer, so...

One of the tricky bits: If you do a memset(0), do you get inttoptr(0) or null? I guess the correct answer is inttoptr(0), but that's not the answer we actually...

I think it's better to wait. LLVM still has some source element type dependent logic for variable index GEPs, and I don't think there's much benefit to making this change...

I think there are other related issues as well, e.g. it looks like "issues closed" is determined based on issues closed in the time frame where I am the assignee,...

The "target extension type" concept being introduced in https://reviews.llvm.org/D135202 may be of interest to you. It addresses similar needs that have been encountered with SPIR-V.

> After transformation to static Qubit and result allocation, we'd need a way to identify particular instance. Today that uses `inttoptr` for named pointer types. Is there a similar strategy...

If you want to preserve the formatting of numbers or strings, you need to do so manually, see for example https://github.com/nikic/PHP-Parser/issues/26. Though in this case the translation is likely in...

We already collect `instructions` and `instructions:u`. I've collected some `cycles` + `cycles:u` data on a different server as well. Overall, it seems to make very little difference. The geomean standard...

> Feel free to close, was just using this for something independent and made the change on my end. Out of curiosity, what are you using it for? > Figured...

Converting `"string"->method()` into `StringObject::method("string")` is easy. The problem is that generally you will not be working on literals, but on variables. If you have `$string->method()`, you do not actually know...