When checking whether an smin is positive, we can move the comparison to one of the inputs if the other is known positive. If the known positive one is the min, then the other can't be negative. If the other is the min, then we compute the min.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Transforms/InstCombine/InstCombineCompares.cpp | ||
---|---|---|
3183 ↗ | (On Diff #49789) | You are correct. |
lib/Transforms/InstCombine/InstCombineCompares.cpp | ||
---|---|---|
3181 ↗ | (On Diff #49846) | This is more work for you, but I think the right thing to do here is introduce an isKnownPositive helper in ValueTracking.h -- doing two recursive walks on the same expression seems wasteful. I'd say lets start with a simple isKnownPositive implementation (maybe one that just looks at !range metadata and computeKnownBits), which we can evolve in the future. |
lib/Transforms/InstCombine/InstCombineCompares.cpp | ||
---|---|---|
3181 ↗ | (On Diff #49846) | I disagree that introducing yet another independent implementation is a good idea. To be blunt, the extra work to make the approach you're requesting work isn't worth it for this patch. I'll just abandon the patch instead because it turns out not to address the case I actually care about. |
lib/Transforms/InstCombine/InstCombineCompares.cpp | ||
---|---|---|
3181 ↗ | (On Diff #49846) |
I grepped around in the codebase, and it looks like SimplifyICmpInst already has this idiom (i.e. isKnownNonNegative(X) followed by isKnownNonZero(X)), so I suppose one more instance of it can't hurt. The avoidable 6-deep traversal still irks me though -- maybe we can leave a FIXME here? |