<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 24, 2013 at 11:01 AM, Arnold Schwaighofer <span dir="ltr"><<a href="mailto:aschwaighofer@apple.com" target="_blank" class="cremed">aschwaighofer@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">In <<a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=184698" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-project?view=revision&revision=184698</a>> Chandler introduced a flag so that we can run the vectorizer after all CG passes. This would prevent the inline from seeing the vectorized code.<br>
</div></blockquote><div><br></div><div>Just for the record, I have no real expectation that this is a good idea yet... But it's hard to collect numbers without a flag of some kind, and it's also really annoying to craft this flag given the current pass manager, so I figured I would get a skeleton in place that folks could experiment with, and we could keep or delete based on this discussion and any numbers.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">
<br>
I see some potential issues:<br>
<br>
* We run a loop pass later again with the associated compile time cost (?)<br></div></blockquote><div><br></div><div>This actually worries me the least -- the tradeoff is between locality and repeatedly analyzing the same loops during the highly iterative CGSCC pass manager (which looks at each function up to 4 times, and may look at the body of a function which gets inlined many more times).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">* The vectorizer relies on cleanup passes to run afterwards: dce, instsimplify, simplifycfg, maybe some form of redundancy elimination<br>
If we run later we have to run those passes again increasing compile time OR<br>
We have to duplicate them in the loop vectorizer increasing its complexity<br></div></blockquote><div><br></div><div>Hopefully, these won't be too expensive. instcombine and simplifycfg shouldn't be this late in the pipeline, but only numbers will really tell. If we need redundancy elimination in the form of GVN, then we're in a lot of trouble, but that doesn't seem likely to be necessary (I hope).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">* The vectorizer would like SCEV analysis to be as precise as possible: one reason are dependency checks that want to know that expressions cannot wrap (AddRec expressions to be more specific):<br>
At the moment, indvars will remove those flags in some cases which currently is not a problem because SCEV analysis still has the old values cached (except in the case that Chandler mention to me on IRC where we inline a function - in which case that info is lost). My understanding of this is that this is not really something we can fix easily because of the way that SCEV works (unique-ifying/commoning expressions and thereby dropping the flags).<br>
A potential solution would be to move indvars to later. The question is do other loop passes which simplify IR depend on indvars? Andy what is your take on this?<br></div></blockquote><div><br></div><div>I think this is far and away the most important question to answer. =] I think there are lots of things that would be improved by preserving SCEVs precision throughout the CGSCC pass manager, but I have no idea how feasible that is. I would also appreciate Dan's insights here.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">The benefit of vectorizing later is that we would have more context at the inlined call site. And it would solve the problem of the inliner seeing vectorized code.<br>
</div></blockquote><div><br></div><div>There's more though in theory (although maybe not in practice today, and I may just be wrong on some of these):</div><div>- It would improve the ability of the vectorizer to reason about icache impact, because it wouldn't think the loop was the only loop in the function only to have it be inlined in 10 places.</div>
<div>- It may form a vectorized loop before inlining which would be handled better by loop idiom recognition after inlining.</div>
<div>- It would prevent turning loops which SCEV-based passes can simply compute and/or delete *after* inlining adds some context into a vectorized loop that may be significantly harder to analyze at this level.</div><div>
<br></div><div>(The last one is the most speculative to me -- it could be that I'm wrong and SCEV and other loop analyses will work just as well on the vectorized loops...)</div><div><br></div><div>All of these share a common thread: the vectorizer somewhat inherently loses information, and thus doing it during the iterative pass manager is very risky as later iterations may be hampered by it.</div>
</div></div></div>