[llvm-dev] RFC: Supported Optimizations attribute

[John McCall via llvm-dev]

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 
> such
> optimization requirements it complies

compiles

> invariant.group

In this proposal, it seems like you're assuming that only the 
invariant.group
metadata needs to be parameterized with a supported_optimization.  
Should you
also decorate all the other structures used as part of this 
optimization, e.g.
the calls to llvm.strip.invariant.group and 
llvm.launder.invariant.group?
This would also allow these intrinsics to be more explicit about exactly 
which
family of invariant.group metadata they're supposed to be 
laundering/stripping,
and correspondingly it would allow LLVM to remove these intrinsics when 
it
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 
> RFC),
> shall not be subject to the above restrictions and shall remain 
> applicable
> 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, 
there are
no existing, non-experimental optimizations using invariant.group where 
it's
crucial that we continue to perform the optimization when linking 
existing .bc
files.  We should just insist that invariant.group has a tag and 
otherwise
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 
> lacking
> them.  By doing so, we may retain at least some level of information
> available to the optimizer, by preserving the annotations already 
> present
> 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 
> through
> a launder, which is a way of conservatively making an arbitrary 
> function
> compliant with the requirements of this particular optimization.

Sure, that's a theoretical future enhancement that we could provide.

John.