[llvm-dev] RFC: Supported Optimizations attribute

[Sanjoy Das via llvm-dev]

I think we should have some bounds on how "badly" a
supported_optimizations tag on a function can affect its semantics.
For instance, can a "supported_optimizations" invariant be that "the
CFG is always structured"?  Or (exaggerating to illustrate the point)
"the function has an equal number of loads and stores"?

-- Sanjoy
On Mon, Dec 3, 2018 at 8:52 PM John McCall via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev