<div dir="ltr">On Tue, Dec 4, 2018 at 2:24 PM John McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>




<div>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 4 Dec 2018, at 13:16, Sanjoy Das wrote:</p>

<blockquote style="border-left:2px solid #777;color:#777;margin:0 0 5px;padding-left:5px">
<p dir="auto">On Mon, Dec 3, 2018 at 11:49 PM John McCall <a href="mailto:jmccall@apple.com" style="color:#777" target="_blank">jmccall@apple.com</a> wrote:</p>

<blockquote style="border-left:2px solid #777;color:#999;margin:0 0 5px;padding-left:5px;border-left-color:#999">
<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 supported_optimizations.<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>

<p dir="auto">other transforms will preserve the apparent semantics of the function and<br>
other transforms will maintain the standard structural rules of LLVM IR.</p>
</blockquote>

<p dir="auto">Ok.  Just to make sure we're on the same page, if this was all there<br>
is we would not need this attribute right?  All LLVM optimizations do<br>
need to preserve semantics and structural properties anyway?</p>
</blockquote>

<p dir="auto">We need this attribute because interprocedural optimizations otherwise<br>
break good-faith optimizations, so yes, my suummary here is missing some<br>
qualification (that I included in the next paragraph, but with a slightly<br>
different spin).  So let me restate this.</p>

<p dir="auto">The designer of a good-faith optimization can rely on this:</p>

<ul>
<li>other transforms will preserve the apparent semantics of the function,</li>
<li>other transforms will maintain the standard structural rules of LLVM IR, and</li>
<li>interprocedural transforms will honor supported_optimizations as mentioned
in Piotr's proposal --- and, in particular, will intersect the
supported_optimizations list whenever moving code into a function.</li>
</ul>

<p dir="auto">[...] I would consider that to be an unacceptable intrusion: intraprocedural transforms should never have to be aware of supported_optimizations (unless they're implementing a good-faith optimization, of course) and interprocedural transforms should only have to be aware of supported_optimizations in the narrow sense outlined by Piotr.  If something about the optimization's representation in IR is unsafe to speculate, it should be made impossible to speculate for standard semantic/structural reasons, like having apparently arbitrary side-effects.</p></div></div></div></blockquote><div>Peanut gallery says: I don't fully understand the use-case or the domain, but this description sounds unworkable to me.</div><div><br></div><div>AIUI, there are two players here: the "brittle optimization" (which relies on some invariant), and the "transform" (which has the power to break that invariant).</div><div><br></div><div>The only two mathematically workable scenarios are:</div><div>(A) The brittle optimization's invariant is "impossible to [break] for standard semantic/structural reasons." Therefore no transform ever needs to know anything about it. The result is a "robust" optimization, and no need for the supported-optimizations flagset.</div><div>(B) The brittle optimization's invariant is, in fact, brittle. Any transform that doesn't explicitly preserve the invariant <i>can and will</i> break the invariant. Therefore, every transform must have its own whitelist of "invariants I know I don't break." Any flag in the supported-optimizations flagset which is not whitelisted by a given transform <i>must</i> be cleared when that transform is applied to the code. (Because, by definition, a transform that doesn't explicitly preserve the brittle invariant must be assumed to break it.)</div><div><br></div><div>my $.02,</div><div>–Arthur</div></div></div>