<div dir="ltr">ok thanks.<div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 14, 2015 at 10:33 AM, 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><br><div class="gmail_quote"><span class="">On Tue, Apr 14, 2015 at 9:53 AM Xinliang David Li <<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a>> wrote:<br><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">On Tue, Apr 14, 2015 at 8:46 AM, 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"><p dir="ltr">I think nick's question is more "is GEP merging really the only problem this causes?"</p></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yes, blind merging (before the fix) can indeed cause more problems. </div></div></div></div><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">
<p dir="ltr">I know the answer is no, because PRE will go crazy and do this if you make it powerful enough to see loop carried dependences and in GCC, it uses an API to detect whether an insertion would be causing issues like this and avoids doing it (which I believe a exactly Nick's suggestion - create a utility others can use to avoid accidentally doing transforms like this in the first place</p></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>IMO, this is a different issue that happens to overlap in scope a little with this one (when there is loop involved).  If LLVM's PRE has the problem of introducing loop carried dependency, we should file a bug (with a test case) to track it.  </div></div></div></div></blockquote><div><br></div></span><div>It does, but only for loads and their addressing calculations right now. It assumes this is always worth eliminating a load for, even if it means introducing loop carried arithmetic.</div><div><br></div><div>see test/Transforms/GVN/pre-load.ll test 9 and test 10.</div><div><br></div><div>If you unify the two PRE's (as i've done), it will happily do so for everything, including induction variables, GEP's, etc.  This is the same issue GCC"s PRE had. It's too smart, and ends up essentially peeling loop iterations/etc.</div><span class=""><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"><div>Does it make sense?   Wei can probably help with that too.</div><div><br></div></div></div></div></blockquote></span><div>I wouldn't worry about it, it will be a while before it becomes an issue for PRE, and we can look at merging heuristics for this and that when NewGVN + NewPRE gets submitted.</div><div><br></div></div></div>
</blockquote></div><br></div>