[llvm-dev] Opaque Pointers Help Wanted

Nikita Popov via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 6 08:50:30 PDT 2021


On Tue, Jul 6, 2021 at 5:22 PM Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:

> 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.
>

Let me clarify how I envision this working:
1. We finalize support for opaque pointers in LLVM.
2. Now we're in a state where both typed pointers and opaque pointers are
supported at the same time, but only typed pointers are heavily tested.
3. There is some period of time where we continue to default to typed
pointers, while opaque pointers already fully work.
4. We switch to opaque pointers by default, and switch all tests to use
opaque pointers.
5. Shortly afterwards, support for typed pointers is dropped.

I really don't think we should compromise on step 5. Or at least, the only
form I would be willing to allow this is that we promise to not
actively/intentionally break typed pointers, but all the testing and fixing
burden is on a 3rd-party.

Where we do have some leeway is step 3, where we have opaque pointer
support that is complete but not enabled by default yet. I think that with
all relevant APIs deprecated, we can be reasonably confident that opaque
pointers continue to work. Personally, I would like to keep this period as
short as possible as well, but if we want to extend the transition, I think
it should be here.

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.
>

My current target would be to complete full opaque pointer support sometime
before the LLVM 14 release, and do the switch shortly after LLVM 14 is
branched. Take this estimate with a grain of salt though :)

Regards,
Nikita

 *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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210706/cd9f247e/attachment.html>


More information about the llvm-dev mailing list