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?
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?
Thanks,
Andy
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Arthur
Eubanks via llvm-dev
Sent: Monday, June 21, 2021 12:03 PM
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] Opaque Pointers Help Wanted
For the opaque pointers project,
https://llvm.org/docs/OpaquePointers.html#transition-plan contains high level
steps for what to do before we can enable opaque pointers. (Looks like the page
hasn't been rebuilt in a while,
https://github.com/llvm/llvm-project/blob/main/llvm/docs/OpaquePointers.rst#transition-plan
contains some more concrete steps)
Essentially almost all of the work boils down to figuring out how to remove
calls to `PointerType::getElementType()` and `Type::getPointerElementType()`.
Everything else derives from that.
Any help with this is welcome and appreciated!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210621/c239bb45/attachment.html>
It looks like Craig's pointed out some cases that come up in LLVM. Perhaps you could try fixing one of the in-tree examples to help explore/set the direction for your out of tree work? Metadata arguments sound like a direction worth exploring. (& would be consistent with the way parameter attributes have been approached - still using a type argument even though the length is all that matters in those cases) On Mon, Jun 21, 2021 at 2:28 PM Kaylor, Andrew via llvm-dev < llvm-dev at lists.llvm.org> 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? > > > > > > 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? > > > > Thanks, > > Andy > > > > > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Arthur > Eubanks via llvm-dev > *Sent:* Monday, June 21, 2021 12:03 PM > *To:* llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* [llvm-dev] Opaque Pointers Help Wanted > > > > For the opaque pointers project, > https://llvm.org/docs/OpaquePointers.html#transition-plan contains high > level steps for what to do before we can enable opaque pointers. (Looks > like the page hasn't been rebuilt in a while, > https://github.com/llvm/llvm-project/blob/main/llvm/docs/OpaquePointers.rst#transition-plan > contains some more concrete steps) > > > > Essentially almost all of the work boils down to figuring out how to > remove calls to `PointerType::getElementType()` and > `Type::getPointerElementType()`. Everything else derives from that. > > > > Any help with this is welcome and appreciated! > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210621/9910383f/attachment.html>
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>