[PATCH] D148120: [InstCombine] Remove scalable get_active_lane_mask calls which are always false

Fri Apr 14 04:53:05 PDT 2023

nikic added a comment.

In D148120#4267931 <https://reviews.llvm.org/D148120#4267931>, @MattDevereau wrote:

> In D148120#4262771 <https://reviews.llvm.org/D148120#4262771>, @nikic wrote:
>
>> Do I understand correctly that this is basically optimizing get.active.lane.mask for the case where we can compute the range of op0 and show that it is always >= op1? And it implements that range calculation for this special case of a post-inc IV?
>
> Yes that's correct. If its impossible for the vectorization factor op0 to be lower than op1 in get.active.lane.mask it will always return an all false mask. This optimization is to fix an edge case kicked out by loop vectorizer which is unable to perform this optimization.
>
>> I don't think this is quite right in that it does not account for addition overflow. That's not actually possible in your specific test cases, but I don't think your implementation has sufficient preconditions to prove this.
>
> Would this be as simple as requiring nsw/nuw flags on the add?

Yes, that should be enough.

FYI there is a matchSimpleRecurrence() helper to check for the general "phi + binop recurrence" pattern.

>> Why does the loop vectorizer generate this code in the first place? Given that it involves reasoning about IVs, it might be more straightforward to handle this in SCEV/LV.
>
> It generates this with low trip counts when LTO is enabled. It tries to vectorize modules with tail folding but the trip count is unknown at this time. After linking it can do a second round of optimizations where the trip count is known and we can replace the get.active.lane.mask call with a constant

Does D148010 <https://reviews.llvm.org/D148010> fix your issue? This is exactly why vectorizations shouldn't be run pre-link.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148120/new/

https://reviews.llvm.org/D148120