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/cd537f1f/attachment.html>
If I remember correctly, these 3 intrinsics need to be redesigned as they
use a type overload on the pointer argument to recover a type. See code
in BPFAbstractMemberAccess::IsPreserveDIAccessIndexCall.
def int_preserve_array_access_index :
DefaultAttrsIntrinsic<[llvm_anyptr_ty],
[llvm_anyptr_ty,
llvm_i32_ty,
llvm_i32_ty],
[IntrNoMem,
ImmArg<ArgIndex<1>>,
ImmArg<ArgIndex<2>>]>;
def int_preserve_union_access_index :
DefaultAttrsIntrinsic<[llvm_anyptr_ty],
[llvm_anyptr_ty,
llvm_i32_ty],
[IntrNoMem,
ImmArg<ArgIndex<1>>]>;
def int_preserve_struct_access_index :
DefaultAttrsIntrinsic<[llvm_anyptr_ty],
[llvm_anyptr_ty,
llvm_i32_ty,
llvm_i32_ty],
[IntrNoMem,
ImmArg<ArgIndex<1>>,
ImmArg<ArgIndex<2>>]>;
~Craig
On Mon, Jun 21, 2021 at 9:03 AM Arthur Eubanks via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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/76b27d65/attachment.html>
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>
Hi Arthur, What's the status of the C API? I don't see any mention of it in the transition plan. Cheers, Nicolai On Mon, Jun 21, 2021 at 6:03 PM Arthur Eubanks via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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 >-- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210622/dccdcf01/attachment.html>