<!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 11:16, Finkel, Hal J. 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 12/4/18 1:49 AM, John McCall via cfe-dev wrote:<br>
<br>
On 4 Dec 2018, at 1:45, Sanjoy Das wrote:<br>
<br>
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"?<br>
<br>
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.<br>
<br>
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:<br>
<br>
* other transforms will preserve the apparent semantics of the function and<br>
* other transforms will maintain the standard structural rules of LLVM IR.<br>
<br>
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).<br>
<br>
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.<br>
<br>
I like these conditions, in terms of bounding what this means.<br>
<br>
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>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">That's a really good point. Applying this to our current use-case, I'm pretty<br>
sure that both return-value propagation and the <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">returned</code> attribute can break<br>
Piotr's devirtualization optimization, so they need to intersect the caller's<br>
list or clear it, respectively. IIRC it used to be the case that <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">returned</code><br>
was mostly honored in the backend for liveness optimizations, i.e. long after<br>
IR constructs like supported_optimizations have stopped being relevant, so<br>
being very pessimistic about it is fine; but I don't know if that's still true.</p>
<p dir="auto">John.</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">Thanks again,<br>
<br>
Hal<br>
<br>
I think that answers your question about what sort of rules we can expect<br>
supported_optimizations to guarantee.<br>
<br>
John.<br>
<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
cfe-dev@lists.llvm.org<<a href="mailto:cfe-dev@lists.llvm.org" style="color:#777">mailto:cfe-dev@lists.llvm.org</a>><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" style="color:#777">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
--<br>
Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory</p>
</blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>