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

Finkel, Hal J. via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 4 08:16:34 PST 2018

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:

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:

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>

More information about the llvm-dev mailing list