[PATCH] D150851: [LoopVectorize] Vectorize select-cmp reduction pattern for increasing integer induction variable

Joseph Faulls via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 31 03:12:14 PDT 2023

Joe added a comment.

In D150851#4546075 <https://reviews.llvm.org/D150851#4546075>, @Mel-Chen wrote:

> In D150851#4542688 <https://reviews.llvm.org/D150851#4542688>, @Joe wrote:
>>> 3. Only target induction variables that determine the branch condition in the loop latch. With this approach, we can indirectly determine whether the induction variable is signed using loop guards, and directly perform vectorization according to the signed overflow is undefined behavior.
>> @Mel-Chen I like this option. But I don't think I understand fully - what's the purposes of determining whether the induction variable is signed?
> We need to determine whether we should use umax or smax in the middle.block. Currently, we have only implemented smax because the application of {1,+,step} unsigned induction variables is relatively uncommon.

That makes sense, thanks for clarifying :)

>> To me, the problem stems from the loss of information that the IV had 32-bit NSW/NUW when IndVarSimplify widens it. Just thinking about alternative options, what if we could retain that information in loop metadata?
> Yes, this is due to the loss of information. If you would like to use metadata, would it be attached to the step instruction of the induction variable?

I (naively) thought this would be attached to the loop metadata, but I haven't looked at implementation details. To be honest, I don't think this is the best option - I prefer option 3.

  rG LLVM Github Monorepo



More information about the llvm-commits mailing list