[PATCH] D34373: [LV] Optimize for size when vectorizing loops with tiny trip count

Taewook Oh via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 20 11:11:14 PDT 2017


twoh added a comment.

In https://reviews.llvm.org/D34373#785642, @hfinkel wrote:

> In https://reviews.llvm.org/D34373#785485, @twoh wrote:
>
> > In https://reviews.llvm.org/D34373#785367, @hfinkel wrote:
> >
> > > In https://reviews.llvm.org/D34373#784975, @twoh wrote:
> > >
> > > > I think this is a right approach, but concerned that the experimental results I shared on https://reviews.llvm.org/D32451 show that it is generally better to not to vectorize the low trip count loops. @Ayal, I wonder if you have any results that this patch actually improves the performance. Thanks!
> > >
> > >
> > > I know that we're currently missing opportunities for large vectorizable loops with low (static)  trip counts. Smaller inner loops are also good candidates for unpredicated vectorization, but we may need to be a bit careful because of modeling inaccuracies and phase-ordering effects (e.g. if we don't vectorize a loop, then we'll end up unrolling it when the unroller runs).
> >
> >
> > Got it. My concern was for small single-level loops with low trip counts, as I observe them pretty frequently. I have no objection accepting this patch and improve the cost estimator separately.
>
>
> Do you mean that you see such loops frequently with dynamically-small trip counts, or with static trip counts? I assume the small loops with (small) static trip counts will generally be unrolled.


Actually you're right. The case I observed was a small static trip count loop completely unrolled and SLP vectorized which actually harms the performance, but not with LV. I think this patch should work if it effectively targets loops that are large enough to not to be unrolled.


https://reviews.llvm.org/D34373





More information about the llvm-commits mailing list