<!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 14:59, 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">On Tue, Dec 4, 2018 at 11:24 AM John McCall <jmccall@apple.com> wrote:</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><p dir="auto">In other words, certain things are UB in functions tagged with<br>
supported_optimizations that are not UB otherwise? This breaks code<br>
hoisting transformations right? I.e.<br>
isSafeToSpeculativelyExecute(Inst) will have to return false if Inst<br>
is in a function with a non-empty supported_optimizations?<br>
</p>
</blockquote><p dir="auto">Good question. I would consider that to be an unacceptable intrusion:<br>
intraprocedural transforms should never have to be aware of<br>
supported_optimizations (unless they're implementing a good-faith<br>
optimization, of course) and interprocedural transforms should only have<br>
to be aware of supported_optimizations in the narrow sense outlined<br>
by Piotr. If something about the optimization's representation in IR<br>
is unsafe to speculate, it should be made impossible to speculate for<br>
standard semantic/structural reasons, like having apparently arbitrary<br>
side-effects.<br>
<br>
I think the right way to formalize this is to say that, while the<br>
good-faith optimization may impose additional UB rules on the function,<br>
it must guarantee that transforms that are well-behaved as described<br>
above --- i.e. that preserve standard structure and semantics and which,<br>
if interprocedural, appropriately honor supported_optimizations --- will<br>
never introduce new UB.</p>
</blockquote><p dir="auto">I see. Would it be correct to say that a good faith optimization `O`<br>
assumes that a certain construct(s), `FOO`, does not occur in the<br>
*trace* of the program within the function tagged with<br>
supported_optimizations={O}?</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I'm not sure that's a useful way of thinking about it. Usually the assumption<br>
will be something more like "Thing 1 does not occur after Event A but before any<br>
occurrence of Event B", and we can clearly mark Events A and B in the IR, but<br>
there might be dozens of different code patterns which all qualify as Thing 1.<br>
This would have to be a good-faith optimization because a non-cooperative<br>
function might not mark Events A and B in the IR, so inlining that into a<br>
cooperative function could lead to miscompilation.</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">Also `FOO` has to be side effecting so<br>
LLVM cannot speculate it into existence (e.g. `FOO` can't be<br>
"getelementptr with a certain property").</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I don't think "side effecting" is <em>always</em> the right rule, but yes:</p>
<ul>
<li><p dir="auto">If something about the sequence shouldn't be speculated, the optimization<br>
should arrange it so that transforms following standard rules can't<br>
speculate it. For example, if you have a language rule that guarantees<br>
that a certain global variable is guaranteed to be constant past a certain<br>
point in the program, you can mark that point with an intrinsic, but that<br>
intrinsic needs to be made non-speculable, and the easiest way to achieve<br>
that is to ensure that it claims to have arbitrary side-effects so that code<br>
which doesn't specifically know about this intrinsic won't speculate it.</p></li>
<li><p dir="auto">In general, all the intrinsic calls, metadata, and so on that participate<br>
in the optimization should be marked in some way that's specific to the<br>
optimization. Formally, this requires that arbitrary transforms that aren't<br>
aware of the optimization can't just <em>sua sponte</em> add optimization-tagged<br>
constructs to a function, as opposed to e.g. cloning or moving them from<br>
somewhere else, but that seems like a pretty safe assumption. :)</p></li>
</ul>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>