[llvm-dev] Opaque Pointers Help Wanted

Tue Jul 6 08:49:03 PDT 2021

>
> Finally, if anyone else shares my concerns it would be helpful to hear
> that, because I realize that just one LLVM contributor (by which I mean my
> company, not me as an individual) can only expect to have so much
> influence.
>

Echoing Andy Kaylor's remarks - this will be initially painful for us to
support in Unity's HPC# Burst compiler.

I guess what I’m asking is that the non-opaque pointer IR form be
> considered deprecated rather than unsupported in the optimizer for at least
> one release after the work is complete and the code to optimize it be kept
> around for that long.
>

For us it'd be great to at least have a single LLVM point release that has
both opaque pointers and the existing typed-pointer support. That'd give us
~6 months to port over all our custom optimization passes and ensure
compliance on the 25-ish platforms we support (EG. LLVM 13 has opaque
pointers, LLVM 14 has *only *opaque pointers).

Cheers,
-Neil.

On Tue, Jul 6, 2021 at 4:36 PM Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> *It would also be very helpful if we could make a reasonable estimate of
> when the opaque pointer work will be complete. I know we have a list of
> what’s left to be done, but it would be very helpful to me if those working
> on this could say when they would like to have it done and when they
> realistically think it will be done.*
>
>
>
> Is this list posted somewhere?
>
>
>
>
>
> --
>
> Krzysztof Parzyszek  kparzysz at quicinc.com   AI tools development
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Kaylor,
> Andrew via llvm-dev
> *Sent:* Tuesday, July 6, 2021 10:22 AM
> *To:* David Blaikie <dblaikie at gmail.com>; llvm-dev at lists.llvm.org
> *Subject:* [EXT] Re: [llvm-dev] Opaque Pointers Help Wanted
>
>
>
> I understand the hard cutover for things like intrinsics and other API
> that are being marked as deprecated. I’m more concerned about the ability
> to continue generating (from clang or other front ends) IR with
> pseudo-typed pointers (by which I mean pointers as they have been and
> mostly are now) and bitcasts that our out-of-tree passes are currently
> depending on and having in-tree passes continue to be able to optimize
> that. I’d like to especially emphasize this latter point. If key in-tree
> passes suddenly stop optimizing code that contains non-opaque pointers and
> bitcasts, that’s effectively a hard cutover for the entire optimizer even
> if the IR is still technically legal.
>
>
>
> I see the problems with doing this. I really do. Once the opaque pointer
> work is complete it will be possible to remove a lot of code that is only
> there to support a “dead” form of the IR, and obviously we’d like to do
> that as soon as we can. I guess what I’m asking is that the non-opaque
> pointer IR form be considered deprecated rather than unsupported in the
> optimizer for at least one release after the work is complete and the code
> to optimize it be kept around for that long. If we make improvements that
> don’t also improve performance with the old form, that’s fine. I just don’t
> want to lose what’s there now.
>
>
>
> It would also be very helpful if we could make a reasonable estimate of
> when the opaque pointer work will be complete. I know we have a list of
> what’s left to be done, but it would be very helpful to me if those working
> on this could say when they would like to have it done and when they
> realistically think it will be done.
>
>
>
> Finally, if anyone else shares my concerns it would be helpful to hear
> that, because I realize that just one LLVM contributor (by which I mean my
> company, not me as an individual) can only expect to have so much influence.
>
>
>
> Thanks,
>
> Andy
>
>
>
> *From:* David Blaikie <dblaikie at gmail.com>
> *Sent:* Friday, July 02, 2021 4:53 PM
> *To:* Kaylor, Andrew <andrew.kaylor at intel.com>
> *Cc:* Nikita Popov <nikita.ppv at gmail.com>; llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] Opaque Pointers Help Wanted
>
>
>
> On Thu, Jul 1, 2021 at 2:49 PM Kaylor, Andrew via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> > My comment was targeted at maintainers of out-of-free frontends and
> targets, who shouldn't assume there will be a long-term period of dual
> compatibility, like there was/is with the new pass manager. If you don't
> want to be stuck on an old toolchain, you need to be ready by the time the
> switch happens.
>
>
>
> I have serious concerns about this. I understand why you want to limit the
> time non-opaque pointers are supported, but having a sharp cutoff feels
> somewhat hostile to those who have a significant amount of out-of-tree code.
>
>
>
> I know the opaque pointer work has been well-publicized and ongoing for
> quite some time, but that’s part of the problem. A lot of work has gone
> into making opaque pointers work, and a corresponding amount if work may be
> required for out-of-tree projects. My company, for example, has been
> following the work in LLVM and working on our own updates, but we’ve been
> allocating resources based on the pace of the open source work, which until
> recently has been fairly slow. We are adjusting our plans in accordance
> with the new push, but it is going to take us some time to catch up.
>
>
>
> At a minimum, I think we need to agree upon a schedule for the transition
> so people can plan their work. Saying that we’re going to cut off support
> for a fundamental feature like this “when the migration is done” makes
> planning impossible. Beyond that, I would vote for keeping the duplicate
> tests around for some period of time.
>
>
>
>
> I think there's still some confusion about what "dual compatibility" means
> - some things are going to be a hard cutover (like intrinsics) - that
> doesn't mean it's going to be sprung on you - we'll have all the pieces in
> place for you to do as much prep as possible, and a healthy amount of
> warning (probably at least a release or so, I should think) - but then
> it'll be a hard cut.
>
> We'll leave tests around for bitcode upgrade, for instance - because that
> must continue working. I'm not sure if it makes sense to leave tests
> covering other LLVM functionality (like transformation passes) using old IR
> (textual or bitcode) - if the actual in-memory IR that it's parsed into is
> the modern typeless pointer IR anyway.
>
> It might be possible to support opaque pointers optionally and have IR
> passes do the right thing for either representation - but that may be
> significantly more work than is practical/suitable, I'm not sure (other
> folks doing more of the work right now might have a better feel for this).
> I can appreciate the desire for this, but I'm not sure it's feasible.
>
> - Dave
>
>
> -Andy
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Nikita
> Popov via llvm-dev
> *Sent:* Thursday, July 01, 2021 11:00 AM
> *To:* paul.robinson at sony.com
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] Opaque Pointers Help Wanted
>
>
>
> On Thu, Jul 1, 2021 at 4:39 PM <paul.robinson at sony.com> wrote:
>
> | My expectation is that after the opaque pointer migration is complete,
> the time the non-opaque pointer mode remains available will be measured in
> days, not years.
>
>
>
> That can be true for textual IR, but we need to retain backward
> compatibility (auto-upgrade) for bitcode for much longer.  I don’t have a
> clear idea of what’s involved (haven’t really been tracking this project)
> but many users/scenarios require bitcode compatibility for long periods.  I
> don’t think we’ve had a true format break since about 4.0?
>
> --paulr
>
>
>
> Sure, we definitely need to retain bitcode compatibility (i.e.
> auto-upgrade to opaque pointers).
>
>
>
> My comment was targeted at maintainers of out-of-free frontends and
> targets, who shouldn't assume there will be a long-term period of dual
> compatibility, like there was/is with the new pass manager. If you don't
> want to be stuck on an old toolchain, you need to be ready by the time the
> switch happens.
>
>
>
> Regards,
>
> Nikita
>
>
>
>  *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Nikita
> Popov via llvm-dev
> *Sent:* Wednesday, June 30, 2021 2:02 PM
> *To:* David Blaikie <dblaikie at gmail.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] Opaque Pointers Help Wanted
>
>
>
> On Tue, Jun 22, 2021 at 7:12 PM David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
>
>
> 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?
>
>
>
> Opaque pointers are not like the pass manager switch, where we can retain
> support for the legacy pass manager at close to zero cost. Nearly all tests
> work the same on both pass managers, so there is little ongoing maintenance
> cost.
>
>
>
> This is not going to be the case with opaque pointers. Doing the switch
> will require changes to nearly the whole test suite. This means that either
> typed pointers will end up being entirely untested (or very weakly tested),
> or we need to duplicate a very large fraction of our tests.
>
>
>
> My expectation is that after the opaque pointer migration is complete, the
> time the non-opaque pointer mode remains available will be measured in
> days, not years.
>
>
>
> Regards,
>
> Nikita
>
>
>
>
>
>
>
>
>
>
>
> *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
> <https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!qYr6p_UsPommoeDmCaNhSX4hvxR3Uy9ym1IhWIFjgm_GXRDjrn7UxxzTONUejGpYGA$>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> <https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!qYr6p_UsPommoeDmCaNhSX4hvxR3Uy9ym1IhWIFjgm_GXRDjrn7UxxzTONUejGpYGA$>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
Neil Henning
Senior Software Engineer Compiler
unity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210706/7133b3e7/attachment.html>