<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 8, 2016 at 10:36 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Apr 8, 2016 at 3:03 PM, Sebastian Pop <span dir="ltr"><<a href="mailto:sebpop@gmail.com" target="_blank">sebpop@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">sebpop removed rL LLVM as the repository for this revision.<br>
sebpop updated this revision to Diff 53095.<br>
sebpop added a comment.<br>
<br>
In <a href="http://reviews.llvm.org/D18798#394160" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18798#394160</a>, @chandlerc wrote:<br>
<br>
> - We also would likely need to see a reasonable analysis of the effect this has on compile time so we understand the tradeoff this is making. My suspicion is that it won't be the correct tradeoff for O2 if it is correct at any level. (See below.) [...]  It makes very little sense IMO to do early-cse and then early-gvn... The only point of early-cse was to be a substantially lighter weight CSE than GVN. If you're going to run GVN anyways to do hoisting, just run GVN.<br>
<br>
<br>
I think there is a misconception of "GVN == PRE":</blockquote><div><br></div></span><div>No, it's GVN == GVN + elimination in LLVM.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> this is because GVN.cpp was<br>
around for a while and the "GVN pass" is a "redundancy elimination" pass.<br>
<br></blockquote></span><div>That is because it is in LLVM :)</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To clarify matters, GVN is an analysis pass,</blockquote><div><br></div></span><div>In the theoretical sense, yes.</div><div>But, as you know, it's not, as currently implemented in LLVM.</div><div>Analysis passes do not modify code.</div><div>GVN modifies code.</div><div>As it runs, it deletes code, it simplifies instruction, etc.</div><div>What you are using is *not* GVN.</div><div>You have taken a very small part of GVN, and reused it.<br></div><div><br></div><div>In particular, you've taken the hash table.  But the hash table only barely performs value numbering.</div><div><br></div><div>In fact, current GVN relies *very* heavily on it's current model of simplification + elimination as it goes to perform *value numbering*.</div><div><br>What you are using will miss *very* obvious cases.</div><div>It's a very trivial value numberer.</div><div><br></div><div>(For example, without elimination-as-it-goes, given</div><div><br></div><div>c = a + 1</div><div>d = c + 1</div><div>e = a + 2</div><div><br></div><div>It will never discover e and c have the same value, etc)</div><div><br></div></div></div></div></blockquote><div><br></div><div><br>^^^ e and d</div><div><br></div></div></div></div>