<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 24, 2013 at 2:59 PM, Nadav Rotem <span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank" class="cremed">nrotem@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>I agree. The vectorizer is a *lowering* pass, and much like LSR and it loses information.  A few months ago some of us talked about this and came up with a general draft for the ideal pass ordering. </div>
</blockquote><div><br></div><div>Where? On the mailing list?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>If I remember correctly the plan was that the second half of the pipe should start with GVN (which currently runs after the loop passes). After that come the loop passes, the Vectorizers (loop vectorization first), and finally LSR, Lower-switch, CGP, etc.  I think that when we discussed this most people argued that the inliner should be before GVN and the loop passes. It would be interesting to see the performance numbers for the new pass order.  </div>
</blockquote></div><br>This doesn't make a lot of sense to me yet.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The inliner, GVN, and the loop passes run together, *iteratively*. They are neither before or after one another. And this is important as it allows iterative simplification in the inliner. It is one of the most critical optimizations for C++ code that LLVM does.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">We can't sink all of the loop passes out of the iterative pass model either, because deleting loops, simplifying them, etc. all directly feed the iterative simplification needed by GVN and the inliner.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">We need a *second* loop pass that happens after the iterative CGSCC walk which does the further optimizations such as (potentially indvars, ) the vectorizers, LSR, lower-switch, CGP, CG. I think we actually want most of the post CGSCC module passes to run after the vectorizers and before LSR to fold away constants and globals that look different after vectorization compared to before, but aren't significantly shifted by LSR and CGP.</div>
</div>