[llvm-dev] [cfe-dev] RFC: Supported Optimizations attribute

[Finkel, Hal J. via llvm-dev]

On 12/4/18 1:49 AM, John McCall via cfe-dev wrote:

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 like these conditions, in terms of bounding what this means.

We might need to be more explicit about what moves code means, as we're run into fuzzy lines before around inter-procedural optimizations (e.g., return-value propagation, using the 'returned' attribute, and variants). Would it work to say "move code with potential side effects"?

Thanks again,

Hal

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

John.



_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/bf603754/attachment.html>