<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 4 Dec 2018, at 1:45, Sanjoy Das wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">I think we should have some bounds on how "badly" a<br>
supported_optimizations tag on a function can affect its semantics.<br>
For instance, can a "supported_optimizations" invariant be that "the<br>
CFG is always structured"? Or (exaggerating to illustrate the point)<br>
"the function has an equal number of loads and stores"?</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Piotr's proposal unfortunately doesn't give us a good name for the class<br>
of optimizations that require being listed in <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">supported_optimizations</code>.<br>
In earlier discussions I called them "brittle", but I can understand why<br>
nobody wants to call their optimization that, so let's call them<br>
"good-faith optimizations" instead since they rely on the good faith of<br>
all the participating code.</p>
<p dir="auto">Every optimization has to know how to maintain the structural rules of<br>
LLVM IR; that's what makes them structural rules. We don't want the set of<br>
structural rules to substantially change because such-and-such good-faith<br>
optimization is in effect because that would require arbitrary transforms<br>
to check the supported_optimizations list before they knew which rules to<br>
follow. Instead, the burden is on the optimization designer to pick IR<br>
constructs that won't be messed up by an arbitrary transform with no special<br>
knowledge of the optimization. The only thing the optimization designer<br>
can rely on is this:</p>
<ul>
<li>other transforms will preserve the apparent semantics of the function and</li>
<li>other transforms will maintain the standard structural rules of LLVM IR.</li>
</ul>
<p dir="auto">For example, if you need arbitrary side-effects to not be re-ordered past<br>
some point in the function, you should put an instruction there that<br>
inhibits that kind of code motion, probably by making it look like a call<br>
to an unknown function. No transform can reorder arbitrary side-effects<br>
across such a call because doing so might change the apparent semantics of<br>
the program. Similarly, if you need a direct use-def link between two<br>
points in the function, you should make the first point define a token<br>
that'll be used by the second point. No transform will break or abstract<br>
that association because that would violate the basic structural rules of IR.<br>
If there's a structural rule that can't be expressed with the current tools<br>
of IR, we can talk about how to fix that --- although tokens are such a big<br>
hammer that I'd be somewhat surprised to hear that something really can't<br>
be expressed at all (but much less surprised to hear that the token rules<br>
are too strong and we'd like other transforms to have more power to change<br>
the code).</p>
<p dir="auto">So the defining property of a good-faith optimization is that:<br>
- there are rules which participating functions are expected to follow on<br>
pain of undefined behavior but which LLVM IR doesn't require every function<br>
to follow, and<br>
- those rules will be preserved by any transform that doesn't move code<br>
between functions and which preserves the apparent function semantics<br>
and maintains the standard structural rules of LLVM IR.</p>
<p dir="auto">I think that answers your question about what sort of rules we can expect<br>
supported_optimizations to guarantee.</p>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>