<!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 15:36, Sanjoy Das wrote:</p>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">
<p dir="auto">On Tue, Dec 4, 2018 at 12:04 PM Arthur O'Dwyer<br>
<a href="mailto:arthur.j.odwyer@gmail.com" style="color:#777">arthur.j.odwyer@gmail.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">Peanut gallery says: I don't fully understand the use-case or the domain, but this description sounds unworkable to me.</p>
<p dir="auto">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).</p>
<p dir="auto">The only two mathematically workable scenarios are:<br>
(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.<br>
(B) The brittle optimization's invariant is, in fact, brittle. Any transform that doesn't explicitly preserve the invariant can and will 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 must 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.)</p>
</blockquote>
<p dir="auto">I think the overarching idea here is that good faith opts will only<br>
rely on invariants that can only be broken by inter-procedural<br>
optimizations. So intra-procedural opts should not need any changes.</p>
<p dir="auto">In a sense this proposal makes function call edges semantically<br>
special; functions calls are no longer yet another kind of control<br>
flow, but they can act as bridges between LLVM IR with different<br>
semantics. Collapsing a function call edge is now a semantically<br>
interesting operation.</p>
</blockquote>
<p dir="auto">Note that this has always been true in some ways. For example, naively<br>
cloning call sites during inlining can change exception semantics; to<br>
make this work correctly you have to reconcile the EH contexts of the<br>
inner and outer calls, which is not always possible if the personalities<br>
differ. Or to pick an even grosser example, you can't just clone a call<br>
to <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">llvm.returnaddress</code> during inlining.</p>
<p dir="auto">Note also that IPO between functions with the same set of supported<br>
optimizations also doesn't involve any change in semantics.</p>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>