[llvm] r176399 - PR14448 - prevent the loop vectorizer from vectorizing the same loop twice.

Chandler Carruth chandlerc at google.com
Sat Mar 2 23:49:17 PST 2013


On Fri, Mar 1, 2013 at 5:33 PM, Nadav Rotem <nrotem at apple.com> wrote:

> Author: nadav
> Date: Fri Mar  1 19:33:49 2013
> New Revision: 176399
>
> URL: http://llvm.org/viewvc/llvm-project?rev=176399&view=rev
> Log:
> PR14448 - prevent the loop vectorizer from vectorizing the same loop twice.
> The LoopVectorizer often runs multiple times on the same function due to
> inlining.
> When this happens the loop vectorizer often vectorizes the same loops
> multiple times, increasing code size and adding unneeded branches.
> 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.
>

I don't think this design really works.

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.

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?

Fundamentally, there seem to be two options for how to design the loop
vectorizer:

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.

2) The vectorizer takes un-vectorized IR and vectorizes it, *assuming* the
input is unvectorized, and thus requiring that it run only once.

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.

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.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130302/20262d0e/attachment.html>


More information about the llvm-commits mailing list