[all-commits] [llvm/llvm-project] c0c714: [InstCombine] Optimize sub(sext(add(x, y)), sext(add...

[Slava Zakharin via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c0c71463f6bca05eb4540b68cdcbd17c916562c9
      https://github.com/llvm/llvm-project/commit/c0c71463f6bca05eb4540b68cdcbd17c916562c9
  Author: Slava Zakharin <szakharin at nvidia.com>
  Date:   2025-06-19 (Thu, 19 Jun 2025)

  Changed paths:
    M llvm/include/llvm/IR/PatternMatch.h
    M llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp
    M llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp
    M llvm/lib/Transforms/InstCombine/InstCombineNegator.cpp
    A llvm/test/Transforms/InstCombine/sub-sext-add.ll

  Log Message:
  -----------
  [InstCombine] Optimize sub(sext(add(x,y)),sext(add(x,z))). (#144174)

This pattern can be often met in Flang generated LLVM IR,
for example, for the counts of the loops generated for array
expressions like: `a(x:x+y)` or `a(x+z:x+z)` or their variations.

In order to compute the loop count, Flang needs to subtract
the lower bound of the array slice from the upper bound
of the array slice. To avoid the sign wraps, it sign extends
the original values (that may be of any user data type)
to `i64`.

This peephole is really helpful in CPU2017/548.exchange2,
where we have multiple following statements like this:
```
block(row+1:row+2, 7:9, i7) = block(row+1:row+2, 7:9, i7) - 10
```

While this is just a 2x3 iterations loop nest, LLVM cannot
figure it out, ending up vectorizing the inner loop really
hard (with a vector epilog and scalar remainder). This, in turn,
causes problems for LSR that ends up creating too many loop-carried
values in the loop containing the above statement, which are then
causing too many spills/reloads.

Alive2: https://alive2.llvm.org/ce/z/gLgfYX

Related to #143219.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications