[llvm-dev] Tail-Loop Folding/Predication

Sjoerd Meijer via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 15 07:45:41 PDT 2019


I am looking for feedback to add support for a new loop pragma to Clang/LLVM.
With "#pragma tail_predicate" the idea would be to indicate that a loop
epilogue/tail can, or should be, folded into the main loop. I see two use
cases for this pragma.

First, this could be interesting for the vectorizer. It currently supports tail
folding by masking all loop instructions/blocks, but does this only when
optimising for size is enabled. This pragma could override the cost-model/opt-level.

Second use case would be the Armv8.1-M MVE vector extension, which supports
tail-predicated hardware loops. This version of hardware loops sets the vector
lanes to be masked, and is thus a nice optimisation that avoids generating a
tail loop when the number of elements processed is not a multiple of the vector
length.

For this use case, the tail predicate pragma could be good user experience
improvement, as it would for example allow this more compact form without
any predicated intrinsics:

  #pragma tail_predicate
  do {
    VLD(..);   // some vector load intrinsic
    VST(..);   // some vector store intrinsic
    ..
  } while (N);

which can then be transformed and predication made explicit through data
dependencies like so:

  do {
    mask = vctp(N);   // intrinsic that generates the mask of active lanes
    VLD(.., mask);
    VST(.., mask);
    ..
  } while (N);

A vector loop in this form can easily be picked up the new hardware loop pass,
and the corresponding tail-predicated hardware loop can be generated. This is
only a small example, but we think for more complicated examples we think
the benefit could be substantial.

I have uploaded a patch for the initial Clang plumbing exercise here:
https://reviews.llvm.org/D64744

Cheers,
Sjoerd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190715/1c00f035/attachment.html>


More information about the llvm-dev mailing list