<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 12/29/2014 02:46 PM, Chandler
Carruth wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0KjrEHEF5jDyCVfhCGHdqcsxuNgBbQX6WUe1Lg=wHJDr9A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Dec 29, 2014 at 2:37 PM,
Philip Reames <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="adM">
<div class="">
<div>On 12/23/2014 04:55 PM, Chandler Carruth wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Dec 23, 2014 at
4:51 PM, Sanjoy Das <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sanjoy@playingwithpointers.com"
target="_blank">sanjoy@playingwithpointers.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"><span>>
Perhaps it would help to explain it
slightly differently: There are<br>
> optimizations which we can only
perform by *removing* any no-wrap flags.
But<br>
> we don't know whether that
optimization or the no-wrap flags is more<br>
> important, and so we have to make a
choice, and the choice is to preserve<br>
> the flags at the expense of the
transformation. Thus, adding flags can<br>
<br>
</span>Is this choice always in favor of
retaining the flags? Or is it a<br>
per-transform decision?</blockquote>
</div>
<br>
per-transform, but at least recently I've been
seeing a trend towards preserving flags.</div>
</div>
<br>
</blockquote>
</div>
</div>
Chandler, thanks for reframing this. This suddenly makes
a lot more sense to me. :)<br>
<br>
This is starting to seem like an canonicalization issue.
If we canonicalized to the form with flags, and deferred
flag stripping until later in the optimization pipeline,
would that get us a better practical result? </blockquote>
</div>
<br>
Well in essence that is what we are currently doing, usually
by stripping the flags in the DAG.</div>
</div>
</blockquote>
I think I wasn't quite clear enough. We currently run InstCombine
in multiple places in the pass ordering. What if we had early runs
of inst combine preserve flags as the first priority. The runs
closer to CGP would instead prioritize any legal optimization,
regardless of whether it preserved flags or not. Another way to
state this would be that we simply pull the point we (potentially)
drop flags a bit earlier in the pipeline - in particular, before the
last point we run instcombine. <br>
<blockquote
cite="mid:CAGCO0KjrEHEF5jDyCVfhCGHdqcsxuNgBbQX6WUe1Lg=wHJDr9A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">This doesn't really get us a butter
practical result because the point of making the transform in
instcombine is to allow the result to in turn re-combine with
something else interestingly.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">The "solution" I really know for this
kind of thing is to explode the space by tracking both forms.
We actually do some of this today. If you have an outer
combine that needs an inner combine that strips flags, you
just write the outer combine to handle the inner expression in
its more complex flag-bearing form. The problem is that this
grows the number of patterns necessary for the outer combine
in a combinatorial way, so there are very severe limits on how
much of this we can do. </div>
</div>
</blockquote>
So essentially this comes down to a case by case profitability
analysis and there's no good answer. Understood. :)<br>
<br>
One interesting observation is that, so far, the cases I've seen
where missing flags inhibit optimization, those flags can be
re-derived from the IR in it's current form (with sufficient
effort). I'm not sure we actually loose that much *in practice* by
dropping flags and re-adding them later if safe to do. Has anyone
run any experiments on this? I will freely admit I don't have a lot
of experience here or a good grasp of the tradeoffs. <br>
<br>
<blockquote
cite="mid:CAGCO0KjrEHEF5jDyCVfhCGHdqcsxuNgBbQX6WUe1Lg=wHJDr9A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">Other approaches to this avoid
"combining" and instead form axioms about values so that they
can represent multiple alternate axioms throughout the
optimization pipeline and select between them very late rather
than committing early. However, I'm not aware of any
production compilers that have managed to make this scale up.
=/</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">I think this is just a fundamental
limitation of a combine-based (that is, through mutations of
the IR) scalar optimizer. The only way you truly avoid it is
to have a mutation-free scalar optimizer which would just be a
totally different design from LLVM's (IMO).</div>
</div>
</blockquote>
I think we're probably all in agreement that these are not practical
answers. :)<br>
<br>
Philip<br>
<br>
</body>
</html>