<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 12/4/18 1:49 AM, John McCall via cfe-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:C7D682F0-6985-498A-88C5-0202E39797E7@apple.com">
<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>
</div>
</div>
</blockquote>
<p>I like these conditions, in terms of bounding what this means.</p>
<p>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"?</p>
<p>Thanks again,</p>
<p>Hal<br>
</p>
<blockquote type="cite" cite="mid:C7D682F0-6985-498A-88C5-0202E39797E7@apple.com">
<div style="font-family:sans-serif">
<div style="white-space:normal">
<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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>