[llvm-dev] RFC: Supported Optimizations attribute
John McCall via llvm-dev
llvm-dev at lists.llvm.org
Mon Dec 3 20:52:17 PST 2018
Thank you for pushing this forward.
On 2 Dec 2018, at 12:47, Piotr Padlewski wrote:
> We propose a fine-grained, function-level solution to this problem,
> originally suggested by John McCall: mark each function with a list of
> optimization requirements it complies
In this proposal, it seems like you're assuming that only the
metadata needs to be parameterized with a supported_optimization.
also decorate all the other structures used as part of this
the calls to llvm.strip.invariant.group and
This would also allow these intrinsics to be more explicit about exactly
family of invariant.group metadata they're supposed to be
and correspondingly it would allow LLVM to remove these intrinsics when
strips invariant.group optimization information.
> As a transitional measure and for backwards compatibility reasons, any
> !invariant.group metadata with an empty argument (i.e. as before this
> shall not be subject to the above restrictions and shall remain
> even when there is no supported_optimizations list provided for the
> enclosing function.
I don't think it's important to support this transitionally. AFAIK,
no existing, non-experimental optimizations using invariant.group where
crucial that we continue to perform the optimization when linking
files. We should just insist that invariant.group has a tag and
strip it during deserialization.
> Possible extensions
> Instead of indiscriminately taking the intersection of supported
> optimizations' lists, we may imagine that some of such optimizations
> may be
> able to provide a conservative set of annotations to a function
> them. By doing so, we may retain at least some level of information
> available to the optimizer, by preserving the annotations already
> in the optimization-compliant function.
> For example, devirtualization may conservatively pass every load and
> function argument through a strip and every store and return value
> a launder, which is a way of conservatively making an arbitrary
> compliant with the requirements of this particular optimization.
Sure, that's a theoretical future enhancement that we could provide.
More information about the llvm-dev