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<mailto: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<mailto: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<mailto:paul.robinson at sony.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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<mailto:dblaikie at
gmail.com>>
Cc: llvm-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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<mailto:aeubanks at
google.com>>
Sent: Tuesday, June 22, 2021 12:15 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at
intel.com>>
Cc: llvm-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/30f5032a/attachment.html>