[llvm-dev] RFC: Supported Optimizations attribute (original) (raw)

Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org
Mon Dec 3 22:45:18 PST 2018

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

More information about the llvm-dev mailing list