[llvm-dev] RFC: Supported Optimizations attribute

[Sanjoy Das via llvm-dev]

On Mon, Dec 3, 2018 at 11:49 PM John McCall <jmccall at apple.com> wrote:
> Piotr's proposal unfortunately doesn't give us a good name for the class
> of optimizations that require being listed in supported_optimizations.
> In earlier discussions I called them "brittle", but I can understand why
> nobody wants to call their optimization that, so let's call them
> "good-faith optimizations" instead since they rely on the good faith of
> all the participating code.
>
> Every optimization has to know how to maintain the structural rules of
> LLVM IR; that's what makes them structural rules. We don't want the set of
> structural rules to substantially change because such-and-such good-faith
> optimization is in effect because that would require arbitrary transforms
> to check the supported_optimizations list before they knew which rules to
> follow. Instead, the burden is on the optimization designer to pick IR
> constructs that won't be messed up by an arbitrary transform with no special
> knowledge of the optimization. The only thing the optimization designer
> can rely on is this:
>
> other transforms will preserve the apparent semantics of the function and
> other transforms will maintain the standard structural rules of LLVM IR.

Ok.  Just to make sure we're on the same page, if this was all there
is we would not need this attribute right?  All LLVM optimizations do
need to preserve semantics and structural properties anyway?

> So the defining property of a good-faith optimization is that:
> - there are rules which participating functions are expected to follow on
> pain of undefined behavior but which LLVM IR doesn't require every function
> to follow, and
> - those rules will be preserved by any transform that doesn't move code
> between functions and which preserves the apparent function semantics
> and maintains the standard structural rules of LLVM IR.

In other words, certain things are UB in functions tagged with
supported_optimizations that are not UB otherwise?  This breaks code
hoisting transformations right?  I.e.
isSafeToSpeculativelyExecute(Inst) will have to return false if Inst
is in a function with a non-empty supported_optimizations?

-- Sanjoy