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

[Chandler Carruth]

On Mon, Jun 24, 2013 at 12:32 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> > In
> > <http://llvm.org/viewvc/llvm-project?view=revision&revision=184698>
> > Chandler introduced a flag so that we can run the vectorizer after
> > all CG passes. This would prevent the inline from seeing the
> > vectorized code.
>
> There are obviously several issues here, and they seem only loosely
> related. Regarding this first one, why is the right answer not to adjust
> (or improve) the inlining heuristic? I understand that this is not easy,
> but the fact remains that, in the end, having the loop inlined, even with
> the extra vectorization checks, is what should be happening (or is the
> performance still worse than the non-vectorized code?). If we really feel
> that we can't adjust the current heuristic without breaking other things,
> then we could add some metadata to make the cost estimator ignore the
> vector loop preheader, but I'd prefer adjusting the inlining thresholds,
> etc. The commit message for r184698 said that the flag was for
> experimentation purposes, and I think that's fine, but this should not be
> the solution unless it really produces better non-inlined code as well.


If all we are doing is inlining first in order to tweak the cost model for
inlining, then I agree with everything you say... but I'm not at all sure
that's the end result.

After inlining, the control flow and even loop structure may look
substantially different than they do before inlining, so the vectorizer may
make a substantially different decision about whether or not to vectorize a
particular loop. As one (somewhat contrived) example, if the loop body is
inlined into a cold region of the enclosing function, the vectorizer might
be able to prioritize code size over performance and skip vectorization.

I think the fundamental problem is that we can't un-vectorize, and the
decision (and strategy) to vectorize is based on a cost model, so the later
we do it the more information we can use in the cost model to make the
correct decision.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130624/47e4376b/attachment.html>