<div dir="ltr">By "folded into the main loop", do you actually mean replace the main loop? So, in effect, running the entire loop under predicate so there is only one loop body?<div><br></div><div>If so, I think that will be a useful pragma in general, but in my opinion, the name is not appropriate since it won't have anything to do with the tail other than how this is accomplished at the moment. Is your thinking that the front end would generate the mask calculation, or are you just leveraging the exiting fold tail by masking and removing the original vectorized loop body?</div><div><br></div><div>I think the proper implementation should really be to generate the predicated instructions in the first place (I'd like to also see actual predicates on the instructions instead of selects, but that is another thread), so I think #pragma loop vectorize(enable) predicated(enable) (or something like that) seems a better choice. This would also allow you to disable loops run under predicate if the cost model in LLVM (or downstream) in the future thinks its best to generate this type of loop and performance numbers suggest otherwise.<div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 15, 2019 at 9:46 AM Sjoerd Meijer via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span>I am looking for feedback to add support for a new loop pragma to Clang/LLVM.<br>
</span>
<div>With "#pragma tail_predicate" the idea would be to indicate that a loop<br>
</div>
<div>epilogue/tail can, or should be, folded into the main loop. I see two use<br>
</div>
<div>cases for this pragma.<br>
</div>
<div><br>
</div>
<div>First, this could be interesting for the vectorizer. It currently supports tail<br>
</div>
<div>folding by masking all loop instructions/blocks, but does this only when<br>
</div>
<div>optimising for size is enabled. This pragma could override the cost-model/opt-level.<br>
</div>
<div><br>
</div>
<div>Second use case would be the Armv8.1-M MVE vector extension, which supports<br>
</div>
<div>tail-predicated hardware loops. This version of hardware loops sets the vector<br>
</div>
<div>lanes to be masked, and is thus a nice optimisation that avoids generating a<br>
</div>
<div>tail loop when the number of elements processed is not a multiple of the vector<br>
</div>
<div>length.<br>
</div>
<div><br>
</div>
<div>For this use case, the tail predicate pragma could be good user experience<br>
</div>
<div>improvement, as it would for example allow this more compact form without<br>
</div>
<div>any predicated intrinsics:<br>
</div>
<div><br>
</div>
<div>  #pragma tail_predicate<br>
</div>
<div>  do {<br>
</div>
<div>    VLD(..);   // some vector load intrinsic<br>
</div>
<div>    VST(..);   // some vector store intrinsic<br>
</div>
<div>    ..<br>
</div>
<div>  } while (N);<br>
</div>
<div><br>
</div>
<div>which can then be transformed and predication made explicit through data<br>
</div>
<div>dependencies like so:<br>
</div>
<div><br>
</div>
<div>  do {<br>
</div>
<div>    mask = vctp(N);   // intrinsic that generates the mask of active lanes<br>
</div>
<div>    VLD(.., mask);<br>
</div>
<div>    VST(.., mask);<br>
</div>
<div>    ..<br>
</div>
<div>  } while (N);<br>
</div>
<div><br>
</div>
<div>A vector loop in this form can easily be picked up the new hardware loop pass,<br>
</div>
<div>and the corresponding tail-predicated hardware loop can be generated. This is<br>
</div>
<div>only a small example, but we think for more complicated examples we think<br>
</div>
<div>the benefit could be substantial.<br>
</div>
<div><br>
</div>
<div>I have uploaded a patch for the initial Clang plumbing exercise here:<br>
</div>
<span><a href="https://reviews.llvm.org/D64744" id="gmail-m_-8342657189186341729LPlnk553447" target="_blank">https://reviews.llvm.org/D64744</a></span><br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Cheers,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Sjoerd.</div>
</div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>