<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 14, 2016 at 6:34 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br><hr><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Daniel Berlin" <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>><br><b>To: </b>"Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br><b>Cc: </b>"llvm-commits" <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>>, <a href="mailto:reviews%2BD22305%2Bpublic%2B92ca108e50bc4651@reviews.llvm.org" target="_blank">reviews+D22305+public+92ca108e50bc4651@reviews.llvm.org</a>, "Ehsan A Amiri" <<a href="mailto:amehsan@ca.ibm.com" target="_blank">amehsan@ca.ibm.com</a>><br><b>Sent: </b>Thursday, July 14, 2016 8:30:09 PM<span class=""><br><b>Subject: </b>Re: [PATCH] D22305: [BasicAA] Strip phi nodes, when all incoming values are the same.<br><br></span><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><br><span class="">(2) is, in theory, the right thing to do. Even if we were to consider uniform PHIs to be anti-canonical, and thus something which should be simplified, we can't simplify often enough to prevent these from blocking useful analysis work. </span></div></div></blockquote><span class=""><div><br></div><div>FWIW, i'm fine with this approach if our approach is going to be as you say - that we will not simplify often enough.</div><div><br></div><div>Right now, as i said, we simplify *everywhere*, and every one of those calls will eliminate this phi node.</div><div><br></div><div>So it's only *this particular path* that misses all those calls.</div><div><br></div><div>For example, if the alias check had gone through a gep of a phi anywhere, it would simplify the phi as part of getunderlyingobject, etc.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">Arbitrary uses of RAUW can create these PHIs, and we can't (and probably shouldn't) run InstCombine in between every other pass. This is a local pattern that stripPointerCasts, and similar functions, can look through.<br></div></div></blockquote><div><br></div><div>Fine with this as long as we maybe stop trying to simplify instructions 8 or 9 times, and instead do it once (max) per instructions, and make this part of it.</div><div><br></div><div>(IE This would mean we would have SimplifyAndGetUnderlyingObject and GetUnderlyingObject, and we simplify once and call the latter or something, or whatever. Not suggesting we decide this second, just suggesting that we agree if this is going to be our general approach).</div></span></div></div></div></blockquote>This is hard because we don't cache the simplifications in any way. It is not like we're updating the IR when we discover some simplification; we're only using the simplified version in place. I'm not sure how to fix this. Maybe we should run InstSimplify a lot more often. It is not as expensive was InstCombine by a large margin (IIRC).<span class=""><br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><br>(3) is also, in theory, the right thing to do. The memdep cache, by necessity, caches negative results. </div></div></blockquote></div></div></div></blockquote></span></div></div></blockquote><div><br></div><div>BTW, i missed this part.  I haven't looked at the memdep caches in a while, but if by "caching negative results" you mean it caches anything other than noalias, that seems .. wrong, since otherwise it would do all the work to prove things are noalias again and again :)</div><div><br></div><div>In that case, you can of course, simply cache that the answer is "no dependencies", and i thought it did.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><span class=""><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">Each GVN iteration, however, performs "information revealing" operations which can make the cached results more conservative than a new query's results.<br></div></div></blockquote><div><br></div><div>Yes.</div><div>It's theoretically possible to make it less expensive than blowing away the whole cache, but so far, experience has told me that fully maintaining the cache becomes slower than redoing the queries :P</div></div></div></div></blockquote></span>I'm not sure how much this helps, but we could/should only clear out the MayAlias results.</div></div></blockquote><div>Again, haven't looked at detail at the caches for a while, but my recollection is this is the vast majority of results.</div><div><br></div></div></div></div>