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

[Andrew Trick]

On Jun 24, 2013, at 3:09 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
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?

These discussions had more to do with formalizing the use of target information within IR passes (legality, instruction-level cost). There were some list threads and offline discussion. I set this aside because I wasn’t sure how it was going to fit with some of the other work in progress, particularly LTO. 

I don’t think there’s any controversy over the high-level goals. But there will be controversy when we start proposing concrete pass ordering changes. 

When I return to work mid-July, I’d be happy to send out some proposed changes for discussion. The first step will be an improved interface for IR-level cost metrics, which we already agreed to some time ago.

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

I don't want to start a centi-thread yet, but here's a very rough idea (leaving many things out):

Canonicalize {
  Func {
    SimpCFG
    SROA-1
    EarlyCSE
  }
  CGSCC {
    Inline
    EarlyCSE
    SimpCFG
    InstCombine
    Early Loop Opts {
      LoopSimplify
      Rotate
      Obvious-Full-Unroll
    }
    SROA-2
    InstCombine
    GVN
    Reassociate
    Late Loop Opts {
      LICM
      Unswitch
    }
    SCCP
    InstCombine
    JT
    CVP
    DCE
  }
}
Lower {
  Target Loop Opts {
    IndvarSimplify
    Vectorize/Unroll
    LSR
  }
  SLP Vectorize
}

We might need to pull some things like exit value replacement out of IndvarSimplify into target-independent loop opts.

-Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130624/0e07b7af/attachment.html>