<div dir="ltr">On Fri, Mar 1, 2013 at 5:33 PM, Nadav Rotem <span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank" class="cremed">nrotem@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Author: nadav<br>
Date: Fri Mar  1 19:33:49 2013<br>
New Revision: 176399<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=176399&view=rev" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-project?rev=176399&view=rev</a><br>
Log:<br>
PR14448 - prevent the loop vectorizer from vectorizing the same loop twice.<br>
The LoopVectorizer often runs multiple times on the same function due to inlining.<br>
When this happens the loop vectorizer often vectorizes the same loops multiple times, increasing code size and adding unneeded branches.<br>
With this patch, the vectorizer during vectorization puts metadata on scalar loops and marks them as 'already vectorized' so that it knows to ignore them when it sees them a second time.<br></blockquote><div><br>
</div><div style>I don't think this design really works.</div><div style><br></div><div style>The very premise of metadata is that removing it is the safe alternative, and you've designed this in such a way that removing metadata is exactly the thing which other optimizations cannot do.</div>
<div style><br></div><div style>Why isn't the solution to "The LoopVectorizer often runs multiple times on the same function due to inlining" simply to not include the loop vectorizer in the CGSCC pass manager that has this behavior, and instead run it in a late stage of the pass manager, once for each function?</div>
<div style><br></div><div style>Fundamentally, there seem to be two options for how to design the loop vectorizer:</div><div style><br></div><div style>1) The vectorizer moves the IR toward a specific "ideal" vectorized form. Running it repeatedly on the same code will either do nothing after the first run, or will iteratively converge on a single form which is then completely stable.</div>
<div style><br></div><div style>2) The vectorizer takes un-vectorized IR and vectorizes it, *assuming* the input is unvectorized, and thus requiring that it run only once.</div><div style><br></div><div style>If the design follows #1, then it belongs in the CGSCC pass manager as part of the loop passes, and running it multiple times over code is fine (except of course for the bugs such as the one you're working on here). If the design follows #2, then it belongs in a late pass much like codegenprep or other "must run only once" passes. I had assumed that the design followed the principle of #1 or I would have objected to its place in the CGSCC pass to begin with.</div>
<div style><br></div><div style>If you choose to go with #2 and move the pass into a late-phase pass, it will pose problems with hand-vectorized loops. There is no fundamental reason why a loop vectorized by this pass in a previous iteration should look different from a hand-vectorized loop. If the LoopVectorizer can't handle vectorized loop inputs, then I think that makes it somewhat less useful.</div>
<div style><br></div><div style>-Chandler</div></div></div></div>