[all-commits] [llvm/llvm-project] 6063e6: [InstCombine] move add after min/max intrinsic

[RotateRight via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6063e6b499c7829b941f94456af493a1ecb93ea1
      https://github.com/llvm/llvm-project/commit/6063e6b499c7829b941f94456af493a1ecb93ea1
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2021-09-26 (Sun, 26 Sep 2021)

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

  Log Message:
  -----------
  [InstCombine] move add after min/max intrinsic

This is another regression noted with the proposal to canonicalize
to the min/max intrinsics in D98152.

Here are Alive2 attempts to show correctness without specifying
exact constants:
https://alive2.llvm.org/ce/z/bvfCwh (smax)
https://alive2.llvm.org/ce/z/of7eqy (smin)
https://alive2.llvm.org/ce/z/2Xtxoh (umax)
https://alive2.llvm.org/ce/z/Rm4Ad8 (umin)
(if you comment out the assume and/or no-wrap, you should see failures)

The different output for the umin test is due to a fold added with
c4fc2cb5b2d98125 :

// umin(x, 1) == zext(x != 0)

We probably want to adjust that, so it applies more generally
(umax --> sext or patterns where we can fold to select-of-constants).
Some folds that were ok when starting with cmp+select may increase
instruction count for the equivalent intrinsic, so we have to decide
if it's worth altering a min/max.

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