This is an archive of the discontinued LLVM Phabricator instance.

[ValueTracking] Teach computeNumSignBits to understand min/max clamp patterns with constant/splat values
ClosedPublic

Authored by craig.topper on Aug 22 2018, 10:59 AM.

Details

Summary

If we have a min/max pair we can do a better job of counting sign bits if we look at them together. This is similar to what is done in the SelectionDAG version of computeNumSignBits for ISD::SMAX/SMIN.

I'm not entirely sure if we can assume the constant is canonicalized to the RHS. So let me know if I need to handle that.

I'm still calling computeNumSignBits on the other input. I don't think SelectionDAG does that. Should the depth limit be bumped by 2 since we went through 2 nodes?

Diff Detail

Repository
rL LLVM

Event Timeline

craig.topper created this revision.Aug 22 2018, 10:59 AM

I'm not entirely sure if we can assume the constant is canonicalized to the RHS.

Instcombine does this in canonicalizeMinMaxWithConstant if the compare has one use. Probably good enough.

Should the depth limit be bumped by 2 since we went through 2 nodes?

Bumping by 1 should be fine given the pattern-matching is cheap; the point of the depth limit is just to prevent non-linear compile-time, anyway.


Can you factor out the clamp matching into a separate helper?

lib/Analysis/ValueTracking.cpp
2385 ↗(On Diff #162002)

CLow and CHigh have to be constants so you can perform this "sle" check?

craig.topper added inline comments.Aug 22 2018, 12:50 PM
lib/Analysis/ValueTracking.cpp
2385 ↗(On Diff #162002)

Maybe we could use computeKnownBits to prove an ordering of Low/High in some other cases using leading zeros/ones?

efriedma added inline comments.Aug 22 2018, 1:29 PM
lib/Analysis/ValueTracking.cpp
2385 ↗(On Diff #162002)

Yes, that would work... but probably best to leave that out for now, until someone finds a case where it matters.

I'm still calling computeNumSignBits on the other input. I don't think SelectionDAG does that.

Thinking about it a bit more, there's probably a good reason for that: if the number of sign bits for the variable input matters, either the SMIN or the SMAX is a no-op.

Hwo tricky would uniform/non-uniform vector support be?

Add a helper function

I'm still calling computeNumSignBits on the other input. I don't think SelectionDAG does that.

Thinking about it a bit more, there's probably a good reason for that: if the number of sign bits for the variable input matters, either the SMIN or the SMAX is a no-op.

That's true, but are we capable of making that optimization today.

I'm still calling computeNumSignBits on the other input. I don't think SelectionDAG does that.

Thinking about it a bit more, there's probably a good reason for that: if the number of sign bits for the variable input matters, either the SMIN or the SMAX is a no-op.

That's true, but are we capable of making that optimization today.

Not sure off the top of my head? But it's easy to implement.

Remove the recursion for clamps

This revision is now accepted and ready to land.Aug 22 2018, 3:56 PM
This revision was automatically updated to reflect the committed changes.