[llvm-dev] Opaque Pointers Help Wanted

[Arthur Eubanks via llvm-dev]

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

> 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
intrinsics.

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>