[llvm-dev] Opaque Pointers Help Wanted

[Nikita Popov via llvm-dev]

On Tue, Jun 22, 2021 at 6:16 PM Kaylor, Andrew via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Honestly, I didn’t (and still don’t) understand enough about the
> intrinsics Craig mentioned to even be sure they were analogous to the case
> I brought up. It seemed like they might be more interested in debug types
> than IR types and may or may not be going down the same paths of reasoning,
> but I just don’t understand what the intrinsics are doing.
>
>
>
> We’re scrambling to get our out-of-tree code caught up with the opaque
> pointer transition. I think the scatter/gather intrinsics are likely to be
> our first useful overlap with the in-tree work to be done, though now that
> I’ve thought about it a bit more, I think the type in that can just be
> inferred from non-pointer arguments. In any case, I guess talking about it
> and agreeing on an approach is a good first step.
>
>
>
> I started trying to mock up some IR for how this might work, but I wasn’t
> entirely happy with it. Specifically, how do you describe an IR type in
> metadata. We could use an undef value in the metadata, similar to what
> Arthur proposed as an argument, but that only moves the ugliness. This is
> kind of what I was thinking
>
>
>
>
>
> define void @f() {
>
>   ptr %p = <however we got %p>
>
>   call void @llvm.some.intrinsic(ptr %p, metadata !1)
>
>   <…>
>
>   return void
>
> }
>
>
>
> define void @llvm.some.intrinsic(ptr, metadata)
>
>
>
> %MyElementTy = type { <whatever> }
>
>
>
> !1 = !{ %MyElementTy undef }
>
>
>
>
>
> I guess that would work, but I don’t really like it. I looked at the way
> TBAA and debug info describe types, but that’s not describing the IR type
> and so it seems simultaneously fragile and too verbose. Is there a better
> way to do this? What about introducing a parameter attribute that would be
> considered required for the intrinsic? Something like this:
>
>
>
>
>
> define void @f() {
>
>   ptr %p = <however we got %p>
>
>   call void @llvm.some.intrinsic(ptr elementtype(%MyElementTy) %p)
>
>   <…>
>
>   return void
>
> }
>
>
>
> ; Requires ‘elementype’ parameter attribute
>
> define void @llvm.some.intrinsic(ptr)
>
>
>
> %MyElementTy = type { <whatever> }
>
>
>
>
>
> Does that feel like a step backward to you? I don’t know how hard it would
> be for front end’s to generate something like that, but it hasn’t the
> benefit that the elementtype would have intentional and well-defined
> semantic meaning.
>
>
>
> Thanks,
>
> Andy
>

For the record, we did end up adding the elementtype() attribute for use by
intrinsics in https://reviews.llvm.org/D105407 /
https://reviews.llvm.org/D106008 and a sample usage for BPF intrinsics in
https://reviews.llvm.org/D106184.

Would be great if you can confirm whether this works for your use-case as
well!

Regards,
Nikita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210904/44e2630e/attachment.html>