[LLVMdev] [llvm] r184698 - Add a flag to defer vectorization into a phase after the inliner and its

Chandler Carruth chandlerc at gmail.com
Mon Jun 24 15:09:52 PDT 2013


On Mon, Jun 24, 2013 at 2:59 PM, Nadav Rotem <nrotem at apple.com> wrote:

> 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.
>

Where? On the mailing list?


> 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.
>

This doesn't make a lot of sense to me yet.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130624/ea0069e9/attachment.html>


More information about the llvm-dev mailing list