<div dir="ltr">Yes that's an issue, I commented on <a href="https://reviews.llvm.org/D61524" target="_blank">https://reviews.llvm.org/D61524</a>.<div>One random hacky idea I had was to add an overloaded parameter that we always pass undef/poison to but is of the type we care about. There's probably a better way though.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 21, 2021 at 10:35 AM Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>def int_preserve_array_access_index : DefaultAttrsIntrinsic<[llvm_anyptr_ty],<br>                                                [llvm_anyptr_ty, llvm_i32_ty,<br>                                                 llvm_i32_ty],<br>                                                [IntrNoMem,<br>                                                 ImmArg<ArgIndex<1>>,<br>                                                 ImmArg<ArgIndex<2>>]>;<br>def int_preserve_union_access_index : DefaultAttrsIntrinsic<[llvm_anyptr_ty],<br>                                                [llvm_anyptr_ty, llvm_i32_ty],<br>                                                [IntrNoMem,<br>                                                 ImmArg<ArgIndex<1>>]>;<br>def int_preserve_struct_access_index : DefaultAttrsIntrinsic<[llvm_anyptr_ty],<br>                                                 [llvm_anyptr_ty, llvm_i32_ty,<br>                                                  llvm_i32_ty],<br>                                                 [IntrNoMem,<br>                                                  ImmArg<ArgIndex<1>>,<br>                                                  ImmArg<ArgIndex<2>>]>;<br><div><br></div><div><div><div dir="ltr">~Craig</div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 21, 2021 at 9:03 AM Arthur Eubanks via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">For the opaque pointers project, <a href="https://llvm.org/docs/OpaquePointers.html#transition-plan" target="_blank">https://llvm.org/docs/OpaquePointers.html#transition-plan</a> 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, <a href="https://github.com/llvm/llvm-project/blob/main/llvm/docs/OpaquePointers.rst#transition-plan" target="_blank">https://github.com/llvm/llvm-project/blob/main/llvm/docs/OpaquePointers.rst#transition-plan</a> contains some more concrete steps)<div><br><div>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.</div><div><br></div><div>Any help with this is welcome and appreciated!</div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>