[llvm-dev] Opaque Pointers Help Wanted

Tue Jun 22 09:21:28 PDT 2021

Oh yes, an attribute type definitely makes much more sense, I like that.
It's essentially the solution used for things like byval pointers.

As for the timeline, we'll have to support mixed opaque pointers and legacy
pointers for a while, we don't want out of tree users to immediately break
as soon as the opaque pointers work is finished up in-tree.

On Tue, Jun 22, 2021 at 10:16 AM Kaylor, Andrew <andrew.kaylor at intel.com>
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
>
>
>
>
>
> *From:* David Blaikie <dblaikie at gmail.com>
> *Sent:* Monday, June 21, 2021 6:00 PM
> *To:* Kaylor, Andrew <andrew.kaylor at intel.com>; craig.topper at gmail.com
> *Cc:* Arthur Eubanks <aeubanks at google.com>; llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] Opaque Pointers Help Wanted
>
>
>
> 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/20210622/989d46a0/attachment.html>