<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 01/14/2017 10:55 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTUyOW0PuiMY_Eprp5weycmaxVn=7yicQzp-VBCJ_tW6MQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<br>
It occurs to me that I understated this. It is all calls that might
throw, but also all calls that might cause the program to exit (or
otherwise not return). Until we have IPA that covers these things
specifically, we probably just need to stop at all calls (except
perhaps readonly/readnone if we disallow side-effect-free
inf-loops). Having IPA for this (via function attributes or
whatever) is something we should get at some point anyway, so that
we can do more-aggressive heap-to-stack transformations, but that's
another story...<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAF4BwTUyOW0PuiMY_Eprp5weycmaxVn=7yicQzp-VBCJ_tW6MQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>