<div dir="ltr">Hi,<div><br></div><div>I wanted to give an update on this topic, as a heads up for what I'd like the plan to be going forward.</div><div><br></div><div>I would like to split the current patch doing the replacement of Alias Set Tracker (AST) with MemorySSA (<a href="https://reviews.llvm.org/D35741" target="_blank">D35741</a>) into more manageable pieces.</div><div>(Note, while the current patch is not the prettiest, it covers all the final functionality. I will rebase this patch on the intermediate patches planned below.)</div><div><br></div><div>A few reasons for the split:<br></div><div>- Preliminary performance results on pathological test cases show that building MemorySSA as a dependency without using it in LICM (i.e., build MemorySSA and also build AST!) leads to prohibitively large compile times, making this a non-option. No surprise here. Hence the flag to enable MemorySSA will be:</div><div>    -> false (do not build MemorySSA, build Alias Set Tracker)</div><div>    -> true (build MemorySSA and use it, do not build Alias Set Tracker)</div><div>- Doing sink/hoist in LICM with MemorySSA is straight-forward, while promotion is difficult to tackle.</div><div>- Having loop passes preserve MemorySSA is a necessary long term step.</div><div>- Easier to review, of course.</div><br>Rough next steps:<br>- Adding MemorySSA as a dependency, to be *built* under a flag in both new and legacy pass managers.<div>- With flag enabled, update MemorySSA in LICM, use it to do sink and hoist, do not do promotion.</div><div>- With flag enabled, do promotion, add MemorySSA sets. This piece can later be replaced, with a different promotion mechanism.</div><div>- Update MemorySSA in LoopUnswitch and LoopRotate<br>- Update MemorySSA in IndVarsimplify, LoopIdiomRecognize, LoopDeletion<br><div><div><br></div></div><div>Patches coming up soon, and feedback welcome.</div><div><br></div><div>Thanks,</div><div>Alina</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 30, 2017 at 10:07 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">Hi,<div><br></div><div>I wanted to give a heads-up that I've been looking into replacing the AliasSetTracker(AST) with MemorySSA in the Loop Invariant Code Motion (LICM) pass.</div><div>I would love to get feedback on the best way to incrementally push in this change.</div><div><br></div><div>Motivation:</div><div>There has been an outstanding issue with using the Alias Set Tracker due to its expensive construction time (quadratic). </div><div>We've had test cases take forever to compile, where the largest time was spent constructing the AST in LICM.</div><div>We've also had to degrade the AST results as a temporary fix to resolve this (D23432).</div><div>The hope is that by using MemorySSA instead, which has linear construction time, we can avoid this issues and decrease compile times.</div><div><br></div><div>Some initial discussion points: </div><div>1. As a first step, I'm looking at having MemorySSA as a dependency only for LICM, in the old pass manager.</div><div>2. In the future, MemorySSA may become one of the loop passes that's readily available for all loops in the new pass manager. This will be a more extensive change and it may require analyzing the overhead of preserving MemorySSA by all loop passes.</div><div>3. As was pointed out in an earlier thread, MemorySSA could be used to implement AliasSetTracker. I am not looking into that. I'm looking into explicitly using MemorySSA, instead of the AliasSetTracker.</div><div>If there are issues with this choice, please raise them here.</div><div><br></div><div>As this is still work in progress, the feedback received will help shape how the replacement gets implemented and merged in.</div><div><br></div><div>Best,</div><div>Alina</div></div>
</blockquote></div><br></div>