[llvm-dev] Opaque Pointers Help Wanted

Arthur Eubanks via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 22 09:15:09 PDT 2021

On Mon, Jun 21, 2021 at 3:27 PM Kaylor, Andrew <andrew.kaylor at intel.com>

> This has probably been discussed somewhere, but I missed it. Can you
> elaborate a bit on this?
>    - Allow bitcode auto-upgrade of legacy pointer type to the new opaque
>    pointer type (not to be turned on until ready)
>       - To support legacy bitcode, such as legacy stores/loads, we need
>       to track pointee types for all values since legacy instructions may infer
>       the types from a pointer operand's pointee type
> I‘m specifically trying to understand what will happen when typed pointer
> support is removed. How will IR with typed pointers be auto-upgraded to
> pure opaque pointer IR? Will the bitcode reader keep some level of typed
> pointer support indefinitely?
Yes, the plan is something along the lines of associating each Value with a
possible pointee type inside the bitcode reader.

> Also, do you have a plan for replacing intrinsics that currently rely on
> pointee types? For example, the load instruction was updated to take an
> explicit type operand but I don’t think we can do the same thing for an
> intrinsic like llvm.masked.load since there is Value for Type. This is an
> easy problem to work around for something like masked.load, but more
> complicated if anyone has a downstream GEP-like intrinsic that needs more
> than the size of an element (spoiler alert: I do have such an intrinsic).
> Would you use a metadata argument?
I don't think metadata can reference an LLVM type. My previous hacky
suggestion was to add a new overloaded parameter with the type you want and
pass undef/poison to it. In any case, we'll have to find a way to fix these
sorts of intrinsics, we shouldn't block the opaque pointers project on some

LLVM already (mostly) treats memory as untyped, what is your intrinsic
attempting to do?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210622/86089e69/attachment.html>

More information about the llvm-dev mailing list