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

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>

On Mon, Jun 24, 2013 at 7:16 PM, Andrew Trick <atrick at apple.com> wrote:
> I don't want to start a centi-thread yet, but here's a very rough
idea
> (leaving many things out):

I actually like the look of this. I'll hack things around so we have a flag
(or set) we can use to experiment. It would be great to get the bits
factored out of IndvarSimplify so that we can run the experiments more
easily.

I'm particularly interested in this if it addresses the regressions I hit
with loop vectorize on by default.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130624/ff8e9b6d/attachment.html>

On Jun 24, 2013, at 7:24 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> 
> On Mon, Jun 24, 2013 at 7:16 PM, Andrew Trick <atrick at apple.com>
wrote:
> I don't want to start a centi-thread yet, but here's a very rough
idea (leaving many things out):
> 
> I actually like the look of this. I'll hack things around so we have a
flag (or set) we can use to experiment. It would be great to get the bits
factored out of IndvarSimplify so that we can run the experiments more easily.
> 
> I'm particularly interested in this if it addresses the regressions I
hit with loop vectorize on by default.
Another thing to look at is whether we need a GVN utility to run after
LICM/Unswitch, or just run a fast non-iterative version of the pass a second
time. Likewise, the vectorizer may rely on GVN now, but it should probably call
a utility instead.

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