<div dir="ltr">Besides that, i guess i don't understand this argument:<div>"<span style="color:rgb(80,0,80);font-size:12.8px">Having a threshold where our ability to optimize falls off a cliff just seems really undesirable"</span></div><div><span style="color:rgb(80,0,80);font-size:12.8px"><br></span></div><div><span style="font-size:12.8px;color:rgb(80,0,80)">This is *already* true in literally every single pass using memdep today, which is most of the memory optimization passes.</span><br></div><div><span style="font-size:12.8px;color:rgb(80,0,80)">It simply *gives* up, and returns "unknown clobber" in a *large variety of cases* due to a large variety of limits.</span><br></div><div><br></div><div>For example: if you have 100 instructions in a block, it won't go past that block, it will stop.</div><div><font color="#500050"><span style="font-size:12.8px"><br></span></font></div><div><font color="#500050"><span style="font-size:12.8px">So does BasicAA for that matter, with it's various depth limits.</span></font></div><div><br></div><div>This simply drops our ability to optimize off a cliff *already*, so we are already down that road.</div><div><br></div><div>If you run GVN </div><div><br>"load a</div><div>98 non-conflicting stores</div><div>load a"</div><div><br></div><div>it will optimize it</div><div><br></div><div>and</div><div><br></div><div>"load a</div><div>99 non-conflicting stores</div><div>load a"</div><div> </div><div>it will do nothing</div><div>etc</div><div><br></div><div>We are *already down that road*.  Whether we fix LICM or not is almost immaterial, as *nothing else* will do optimization. We already know we can't fix the main thing sanely (if you partition in memdep, and associate virtual memory accesses with each thing representing the partitions, congrats, you've basically invented memoryssa).</div><div><br></div><div>MemorySSA is the thing walking us back up the road.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 20, 2016 at 12:56 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">It is already enabled by default for GVNHoist, which is enabled by default at O1 and O2.<div>There are patches in progress to convert other passes under review.</div><div><br></div><div>We just branched for 3.9, and are in the midst of significant pass manager work, so i am not sure having a super-near term date makes sense?</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 20, 2016 at 12:54 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 08/20/2016 12:38 PM, Hal Finkel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
hfinkel added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D23432#521624" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2343<wbr>2#521624</a>, @reames wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am not actively objecting to this patch, but I really don't like the overall direction here.  Having a threshold where our ability to optimize falls off a cliff just seems really undesirable.  As Hal pointed out, there are likely options for summarizing alias sets to allow quicker AA queries.  How much have we explored that design space?<br>
</blockquote>
<br>
My understanding from the discussion is that all uses of the ASTracker are going to be replaced with MemorySSA-based algorithms; that is why I was okay with this (for now). If we still need an AST concept, then we'll want to do something more sophisticated.<br>
</blockquote></span>
I haven't been following the MemorySSA work recently.  Do we have a concrete near term date in mind for enabling MemorySSA?  If not, I am not okay with an attitude of "MemorySSA will fix everything... someday".  That's a very dangerous road to start walking down.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>