[llvm-dev] RFC: Supported Optimizations attribute

[John McCall via llvm-dev]

On 4 Dec 2018, at 1:45, Sanjoy Das wrote:

> 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"?

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.

For example, if you need arbitrary side-effects to not be re-ordered past
some point in the function, you should put an instruction there that
inhibits that kind of code motion, probably by making it look like a call
to an unknown function.  No transform can reorder arbitrary side-effects
across such a call because doing so might change the apparent semantics of
the program.  Similarly, if you need a direct use-def link between two
points in the function, you should make the first point define a token
that'll be used by the second point.  No transform will break or abstract
that association because that would violate the basic structural rules of IR.
If there's a structural rule that can't be expressed with the current tools
of IR, we can talk about how to fix that --- although tokens are such a big
hammer that I'd be somewhat surprised to hear that something really can't
be expressed at all (but much less surprised to hear that the token rules
are too strong and we'd like other transforms to have more power to change
the code).

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.

I think that answers your question about what sort of rules we can expect
supported_optimizations to guarantee.

John.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/923cb90d/attachment.html>