[all-commits] [llvm/llvm-project] bfb915: [InstCombine] add tests for 'sub nuw' with zext; NFC

[Sanjay Patel via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bfb915ec8bd057c566772b6f620a5ad3f55e9e17
      https://github.com/llvm/llvm-project/commit/bfb915ec8bd057c566772b6f620a5ad3f55e9e17
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-06-19 (Sun, 19 Jun 2022)

  Changed paths:
    M llvm/test/Transforms/InstCombine/sub.ll

  Log Message:
  -----------
  [InstCombine] add tests for 'sub nuw' with zext; NFC


  Commit: 4022551a154e01ca5347629fd429ca04b36801e0
      https://github.com/llvm/llvm-project/commit/4022551a154e01ca5347629fd429ca04b36801e0
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-06-19 (Sun, 19 Jun 2022)

  Changed paths:
    M llvm/lib/Analysis/ValueTracking.cpp
    M llvm/test/Transforms/InstCombine/sub.ll

  Log Message:
  -----------
  [ValueTracking] recognize sub X, (X -nuw Y) as not overflowing

This extends a similar pattern from D125500 and D127754.
If we know that operand 1 (RHS) of a subtract is itself a
non-overflowing subtract from operand 0 (LHS), then the
final/outer subtract is also non-overflowing:
https://alive2.llvm.org/ce/z/Bqan8v

InstCombine uses this analysis to trigger a narrowing
optimization, so that is what the first changed test shows.

The last test models a motivating case from issue #48013.
In that example, we determine 'nuw' on the first sub from
the urem, then we determine that the 2nd sub can be narrowed,
and that leads to eliminating both subtracts.

here are still several missing subtract narrowing optimizations
demonstrated in the tests above the diffs shown here - those
should be handled in InstCombine with another set of patches.


Compare: https://github.com/llvm/llvm-project/compare/5d7e63fb4f26...4022551a154e