<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
-> The code now is correct (modulo other bugs =)) in presence of undefs<br>
-> This allows us to keep the same lattice height and therefore all<br>
the nice termination/convergence properties/bounds (see the paper for<br>
reference).<br>
-> This allows to remove a lot of code (pretty much the resolver) and<br>
makes the algorithm easier to understand<br></blockquote><div><br></div></div></div><div>How does this eliminate the need for the resolver? Without the resolver, what will plug in values for the undef's?</div><span class=""><div> </div></span></div></div></div></blockquote><div><br></div><div>You don't need a separate resolver to plug in values for the undefs.</div><div><br></div><div>Even if you wanted to super-optimize them, you wouldn't do it the way the resolver does it (there are better strategies :P)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-> SCCP doesn't need anymore to roll its own tiny constant folder<br>
where we need to add cases everytime we realize there's something<br>
missing, instead, it can leverage the full power of ConstantFolding<br>
when something folds to undef.<br></blockquote><div><br></div></span><div>Can you elaborate on why SCCP currently needs to "roll its own tiny constant folder"? I wasn't able to understand it from just the context here.</div><div><br></div><div>-- Sean Silva</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><div class="h5">
-> Makes SCCP *slightly* faster.<br>
<br>
#### (Potential) drawbacks:<br>
-> This change the behavior of `phi` handling, i.e. we lose some cases<br>
as we force phi to overdefined if not the values are constant. I<br>
measured the impact on the llvm-testsuite and on some internal<br>
benchmarks and I wasn't able to measure any substantial different in<br>
runtime performances. If you care about this case, please speak up =)<br>
(or try the patch and report regressions). There are probably ways to<br>
make this working but we (see [4], comment 7 and 8) think the gain in<br>
precision is not worth the complexity (and what's here is *much much*<br>
better than what's in the tree as it tries at least to be correct).<br>
<br>
#### Plan for integration<br>
The patch is available at <a href="https://reviews.llvm.org/D28177" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2817<wbr>7</a><br>
Any comments/feedback/testing is definitely welcome. This is a<br>
self-contained change.<br>
<br>
#### (Possible) future work<br>
If this goes in I'd like to implement constant propagation for missing<br>
IR constructs (in particular vectors), and make sure SCCP is on par<br>
with the other two costant propagation passes we have in llvm (and<br>
maybe garbage collect them).<br>
Danny suggested an improvement could be that of propagating facts in<br>
both directions (GCC does that as a separate pass<br>
<a href="https://gcc.gnu.org/svn/gcc/trunk/gcc/gimple-ssa-backprop.c" rel="noreferrer" target="_blank">https://gcc.gnu.org/svn/gcc/tr<wbr>unk/gcc/gimple-ssa-backprop.c</a>)<wbr>. I have<br>
no immediate plans to work on this (I suspect NewGVN and other places<br>
will keep me busy for a while), but I hope to eventually get there.<br>
<br>
#### Thanks<br>
Eli Friedman and Daniel Berlin provided very insightful<br>
conversations/suggestions on how to tackle the problems, and provided<br>
early feedback on the change (other than reviewing large part if not<br>
all my previous work on SCCP).<br>
<br>
<br>
[1] <a href="https://www.cs.utexas.edu/users/lin/cs380c/wegman.pdf" rel="noreferrer" target="_blank">https://www.cs.utexas.edu/user<wbr>s/lin/cs380c/wegman.pdf</a><br>
[2] <a href="http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161107/403212.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermai<wbr>l/llvm-commits/Week-of-Mon-<wbr>20161107/403212.html</a><br>
[3] <a href="https://llvm.org/bugs/show_bug.cgi?id=30448" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug<wbr>.cgi?id=30448</a><br>
[4] <a href="https://llvm.org/bugs/show_bug.cgi?id=30966#c8" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug<wbr>.cgi?id=30966#c8</a><br>
</div></div><span class="m_1203141306893361756gmail-HOEnZb"><font color="#888888"><div><div class="h5"><br>
--<br>
Davide<br>
<br>
"There are no solved problems; there are only problems that are more<br>
or less solved" -- Henri Poincare<br></div></div>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</font></span></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>