[llvm-dev] [Proposal][RFC] Epilog loop vectorization
Adam Nemet via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 22 09:52:01 PST 2017
> On Feb 22, 2017, at 1:57 AM, Nema, Ashutosh via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> This is a proposal about epilog loop vectorization.
> Currently Loop Vectorizer inserts an epilogue loop for handling loops that don’t have known iteration counts.
> The Loop Vectorizer supports loops with an unknown trip count, unknown trip count may not be a multiple of the vector width, and the vectorizer has to execute the last few iterations as scalar code. It keeps a scalar copy of the loop for the remaining iterations.
> Loop with the large width has a high possibility of executing many scalar iterations.
> i.e. i8 data type with 256bits target register can vectorize with vector width 32, with that maximum trip count possibility for scalar(epilog) loop is 31, which is significant & worth vectorizing.
> Large vector factor has following challenges:
> 1) Possibility of remainder iteration is substantial.
> 2) Actual trip count at runtime is substantial but not meeting minimum trip count to execute vector loop.
> These challenges can be addressed by mask instructions, but these instructions are limited and may not be available to all targets.
> By epilog vectorization our aim to vectorize epilog loop where original loop is vectorized with large vector factor and has a high possibility of executing scalar iterations.
> This require following changes:
> 1) Costing: Preserve all profitable vector factor.
> 2) Transform: Create an additional vector loop with next profitable vector factor.
Is this something that you propose to be on by default for wide VPU architectures without masking support? I.e. how widely is this applicable? If not then perhaps a better strategy would be to just annotate the remainder loop with some metadata to limit the vectorization factor and just rerun the vectorizer.
> Please refer attached file (BlockLayout.png) for the details about transformed block layout.
> Patch is available at: https://reviews.llvm.org/D30247 <https://reviews.llvm.org/D30247>
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev