[llvm-dev] Opaque Pointers Help Wanted

[David Blaikie via llvm-dev]

On Tue, Jun 22, 2021 at 9:39 AM Kaylor, Andrew via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> > 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.
>
>
>
> It looks like I just missed your response before getting my response to
> David in flight. Yes, I see the metadata problem. I don’t like the
> undef/poison approach, but I agree that it would technically work.
>
>
>
> I completely agree that we should solve this problem rather than block the
> opaque pointer project because of it. Nevertheless, we’ll need to solve the
> problem.
>
>
>
>
>
> > LLVM already (mostly) treats memory as untyped, what is your intrinsic
> attempting to do?
>
>
>
> It’s kind of like a GEP but more specialized. It’s doing a pointer
> calculation based on multidimensional composite types with a shape that is
> known at runtime but unknown at compile time, and we have a front end
> that’s able to supply enough info to make this useful.
>
>
>
>
>
> > 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.
>
>
>
> Is there any consensus on the scope of “for a while”? Like, how many major
> releases after the opaque pointer work is complete? My manager would very
> much like to know the answer to this question. :-) I’ve been trying to
> prepare for the buffer being as little as one major release after the
> in-tree work is done but hoping for more. I expect there are others with a
> similar interest.
>

By default I'd vote for one major release - but likely the ongoing burden
of carrying it for a bit longer if some significant contributors would
benefit from extra time it's probably going to be pretty harmless to keep
it around a bit longer, I think?


>
>
>
>
>
>
>
>
> *From:* Arthur Eubanks <aeubanks at google.com>
> *Sent:* Tuesday, June 22, 2021 12:15 PM
> *To:* Kaylor, Andrew <andrew.kaylor at intel.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] Opaque Pointers Help Wanted
>
>
>
>
>
>
>
> 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?
> _______________________________________________
> 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/9e53ddc1/attachment.html>