<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 27, 2017 at 9:46 AM, Alina Sbirlea <span dir="ltr"><<a href="mailto:alina.sbirlea@gmail.com" target="_blank">alina.sbirlea@gmail.com</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"><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_-322516691099399037gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
> FWIW I suspect MemorySSAAliasSets will be too slow for use by anything for<br>
> real.<br>
<br>
</span>I was under the impression is that it should be no worse than<br>
AliasSetTracker,</blockquote><div><br></div></span><div>This is true, but AST is badly N^2 already, so realize i'm in the boat of "AST is too slow for anything to use for real".</div><div><br></div><div>I also very much do not want to see *new* passes using MemorySSAAliasSets to do anything.</div><span class="m_-322516691099399037gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> and better in some cases (large blocks with very few<br>
memory operations). </blockquote><div><br></div></span><div>In the case of promoting loads alone, AST is not necessary at all.</div><div>In the case of promoting loads and stores, the way our LICM does it means it's still going to be N^2.</div><div>You will save some walking time.</div><div><br></div><div>You also end up back in a world where clients are trying to do direct aliasing queries, which sucks.</div><span class="m_-322516691099399037gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Otherwise I don't see a reason to do this.<br></blockquote><div><br></div></span><div>I'm torn.</div><div>It buys you something, but i also suspect at this level of complexity, we could have just rewritten licm and build a memoryssi or a multi-phi memoryssa or whatever it took to make handling stores fast.</div><div><br></div><div>Sigh.</div></div></div></div></blockquote><div><br></div></span><div>Agreed on those points; the patch description talks about the problem with promotion. </div></div></div></div></blockquote><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>Question is, is it ok to have this functionality checked in as is until a rewrite of licm or an alternative for aliasing stores exists?</div><div><br></div></div></div></div></blockquote><div><br></div><div>I'm not opposed to it if it's actually a win, of course :)</div><div><br></div></div></div></div>