It would be good to also have test cases (for the ssubo->saddo canonicalization, not the nsw fold) where the vector constant argument of the ssubo has undef or is non-splat. This is one of those rare cases where we can easily support them, because the necessary machinery is already in place (see https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineCalls.cpp#L2194).

In D59006#1438184, @lebedev.ri wrote:

This LG, but i'm not sure i understand how this is related to D59066?
Here, we are clearly end up with no select in ASM.
But in D59066 we expand to this pattern.
So there is something else that is able to do the transform that we do manually in D59066?
Should D59066 be doing something else to simply trigger the existing transform?

I've updated the AMDGPU tests to check for min(max(x, 17), 12) being constant folded to 12. The reverse test for min(max(x, 12), 17) already exists, so it doesn't seem like adjusting those constants to prevent the constant folding would make sense.

Update AMDGPU tests, update for more InstCombine test changes.

Reverted this in rL356424 due to AMDGPU smed3.ll and umed3.ll test failures. Likely some constants will need to be adjusted to avoid always-true/false conditions.

Base on D59511.

Move simplifyICmpWithAbsNabs() logic into computeConstantRange(). This eliminates the duplicate matchSelectPattern() call, and is more general (e.g. we can also benefit from this for the constant range based overflow checks).

@spatel I've created D59506 for the InstSimplify change.

Rebase and remove constant vector code.

Thanks!

Any particular reason to limit this to rotates only? This should be valid for funnel shifts in general.

Switch to ConstantRange::fromKnownBits().

Add exhaustive test.

I'd prefer that we IR simplify our way out of this infinite loop instead of looking the other way though. Ie, can we get this in instsimplify using a ConstantRange?

Add visitORCommutative() function to reduce code duplication when matching commuting patterns.

Handle more commuted variants.

Are there any concerns of performance impact of using ConstantRange() here ?

So is it NFC (not counting the AlwaysOverflows) or not?

D59386 implements the full optimization for the unsigned case, and D59450 is preparation for the signed add case, though there's a few more followups necessary there (for signed sub, for extension to use computeConstantRange, and for handling AlwaysOverflows).

Unlikely that I'll try to push this one through.

Remove AArch64 specific portion, which has been handled by rL356299.

Fix typo in comment.