<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 14, 2017 at 6:47 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><div><div class="gmail-h5">
<p><br>
</p>
<div class="gmail-m_500654379587256154moz-cite-prefix">On 01/14/2017 07:19 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Jan 14, 2017 at 4:47 PM, Hal
Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-m_500654379587256154gmail-">
<p><br>
</p>
<div class="gmail-m_500654379587256154gmail-m_8665129088256811335moz-cite-prefix">On
01/14/2017 05:21 PM, Daniel Berlin wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>In any case, if you want to play with it,
it's here:</div>
<div><a href="https://github.com/dberlin/llvm-gvn-rewrite/tree/newgvn-predicateinfo" target="_blank">https://github.com/dberlin/llv<wbr>m-gvn-rewrite/tree/newgvn-pred<wbr>icateinfo</a><br>
</div>
<div><br>
</div>
<div>-print-predicateinfo -analyze will give you
info.</div>
<div><br>
</div>
<div>-newgvn will process simple equality and
inequality right now using that info[1]</div>
<div><br>
</div>
<div>This is pretty much as cheap as you can make
it.<br>
</div>
<div>We compute it in O(number of uses of
comparison operations that are used in
terminators) worst case time. </div>
<div>So it's not even O(number of instructions)
unless your program is only comparisons and
branches :P<br>
</div>
<div><br>
</div>
<div>This includes pruning - it will not insert
predicate info copies except where they are
actually used on a branch.</div>
<div><br>
</div>
<div>(the same O(uses) algorithm works for general
SSA renaming as well)</div>
<div><br>
</div>
<div>Adding assume support would just require
coming up with a copy operation, and doing local
numbering in the assume blocks only (so we get
def vs use order right in that block).</div>
</div>
</blockquote>
<br>
</span> Looks good, thanks! The code you have in
PredicateInfo::buildPredicateI<wbr>nfo looks essentially
like the code I have in AssumptionCache::updateAffecte<wbr>dValues;
we just need to update the PredicateInfo version to
catch a few more cases that the assumptions need.<br>
</div>
</blockquote>
<div><br>
</div>
<div>I'm working on it.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> <br>
I don't understand what you mean by "in the assume
blocks only." I'd think we'd need to treat these just
like dominating conditional-branch conditions, so we'd
need to rename all uses dominated by the assumption in
all blocks.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, i meant The local ordering only has to be done in
the assume block only, because global ordering is taken
care of by dominator tree.</div>
<div>The way it works is by sorting in DFS order (to avoid
walking the entire dominator tree just for ordering
effect).</div>
<div>Globally, we have DFS of dominator tree to order
things.</div>
<div>Inside the same block, you need a local DFS order
(order of appearance)</div>
<div>The only blocks where you need such an ordering is
blocks with assumes, because we don't know where in the
block the assume is.</div>
<div>For conditionals, the value gets generated on the
true/false edge, so it always comes first in the block,
and we don't need any real single-block ordering for it.</div>
<div><br>
</div>
<div>WIthout a local ordering for assume, we will try to
rename<br>
</div>
<div><br>
</div>
<div>bb1:<br>
<br>
</div>
<div>foo = 5</div>
<div>use foo</div>
<div>result = icmp eq foo, bar</div>
<div>assume(result)</div>
<div><br>
</div>
<div>into </div>
<div><br>
</div>
<div>foo = 5</div>
<div>use foonew</div>
<div>result = icmp eq foo, bar</div>
<div>assume(result)</div>
<div>foonew = predicateinfo(foo)</div>
<div><br>
</div>
<div>because we won't realize the def comes after the use.</div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
Makes sense. Thanks for explaining.<span class="gmail-"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div><br>
</div>
<div>Though now that i re-read the lang-ref, it says:</div>
<div>"<span>The
intrinsic allows the optimizer to assume that the
provided condition is always true whenever the control
flow reaches the intrinsic call."</span></div>
<div><span><br>
</span></div>
Does this mean i can make go upwards as long as the assume
post-dominates the use?</div>
</div>
</div>
</blockquote>
<br></span>
Yes. The current code even checks for this, at least in a restricted
sense, at the end of llvm::isValidAssumeForContext. For assumes and
context instructions in the same block, if the assume post-dominates
but everything in between is safe to speculate, then we'll still
find it. Speculation safety is a stronger condition than necessary
(because faults that are UB get to travel backwards too, so we don't
need to guard against them), but does serve to limit the cost of the
search while still allowing innocent code motion not to affect our
ability to apply assumptions. If we had a more-efficient way to
check dominance, we might be more forgiving, although we still need
to check that there are no potentially-throwing calls in between.</div></blockquote><div><br></div><div>Interesting. In the renamer i use, it would be trivial to just throw the throwing calls into it, and sort them where they go.</div><div>Then when you see them, you pop everything off the stack and start again.</div><div><br></div><div>Or whatever.</div><div><br></div><div>Seems easy enough, but not sure of the cost :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">If so, the above would be valid as
long as i change it to:<br>
<br>
</div>
<div class="gmail_quote">
<div>foo = 5</div>
<div>foonew = predicateinfo(foo)</div>
<div>use foonew</div>
<div>result = icmp eq foo, bar</div>
<div>assume(result)</div>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">which we could do easily.</div>
</div>
</div>
</blockquote>
<br></span>
Sounds good to me. The foonew does not need to be dominated by the
result because that's a side table?</div></blockquote><div><br></div><div>Correct.</div><div>Right now they are phis so they have to go at the beginning of the block (and i can do assumes as phis in this model given the above), but once they aren't, we would place them right before first use, since we are guaranteed that is dominated by the def.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
-Hal</font></span><span class="gmail-"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote"><br>
</div>
</div>
</div>
</blockquote>
<br>
<pre class="gmail-m_500654379587256154moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</span></div>
</blockquote></div><br></div></div>