[all-commits] [llvm/llvm-project] 234a84: [InstCombine] add test for min/max intrinsic with ...

[Sanjay Patel via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 234a8422c912ec102e23cc06999245945b53182f
      https://github.com/llvm/llvm-project/commit/234a8422c912ec102e23cc06999245945b53182f
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-02-17 (Thu, 17 Feb 2022)

  Changed paths:
    M llvm/test/Transforms/InstCombine/minmax-intrinsics.ll

  Log Message:
  -----------
  [InstCombine] add test for min/max intrinsic with constant expression; NFC


  Commit: 58df2da0540c0ae0bb4f72c382fae0b4fbedae1c
      https://github.com/llvm/llvm-project/commit/58df2da0540c0ae0bb4f72c382fae0b4fbedae1c
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-02-17 (Thu, 17 Feb 2022)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
    M llvm/test/Transforms/InstCombine/minmax-intrinsics.ll

  Log Message:
  -----------
  [InstCombine] push constant operand down/outside in sequence of min/max intrinsics

A generalization like this was suggested in D119754.
This is the inverse direction of D119851,
and we get all of the folds there plus the one that was missed.

There is precedence for this kind of transform in instcombine
with "or" instructions (but strangely only with that one opcode AFAICT).

Similar justification as in the other patch:
The line between instcombine and reassociate for these kinds of folds
is blurry. This doesn't appear to have much cost and gives us the
expected wins from repeated folds as seen in the last set of test diffs.

Differential Revision: https://reviews.llvm.org/D119955


Compare: https://github.com/llvm/llvm-project/compare/092a5bb72ba8...58df2da0540c