This lines up with what we do for regular subtract and it matches up better with X86 assumptions in isel patterns that add with immediate is more canonical than sub with immediate.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/test/CodeGen/X86/sub-with-overflow.ll | ||
---|---|---|
86 ↗ | (On Diff #192945) | This is somewhat a regression, but we now generate the code we would get from sadd.with.overflow.i32 with an immediate of -1. So we probably need a more complete canonicalization to icmp when the data result isn't used. |
cc @lebedev.ri @nikic @dlrobertson - do we have a patch proposal for this transform in IR? (I'm not finding it now.)
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
3049 ↗ | (On Diff #192945) | I think you're right. This generates the opposite value for the overflow flag for INT_MIN. |
Don't think we have a patch open for this yet, but @dlrobertson added some tests for this transform in D59653 already, so probably the instcombine patch will come as well...
Sorry for the delay. Was planning on posting a patch for the IR transform in the next day or so.
D60061 is the sibling patch for IR. Does that make the backend patch unnecessary? If not, then let's make sure the behavior is consistent between these patches.
-Add a check for INT_MIN.
-Update a SystemZ test I missed cause I only had X86 building previously. I think this one of these cases is a regression, but that's probably also going to happen with the InstCombine version of this patch too. So probably needs to be fixed regardless.
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
3047 ↗ | (On Diff #193380) | I don't think this path would be hit post-D60061 right? Would this be for the case that opt is run without instcombine? Also D60061 uses Constant and isNotMinSignedValue. Is there a reason not to use N1C->getConstantIntValue()->isNotMinSignedValue here too? Are there pros/cons to either one? |
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
3047 ↗ | (On Diff #193380) | Not sure if this can come up in real code after D60061, but we have lit tests here that change. Should we update those to post D60061 code instead? IsNotMinSignedValue does dyn_cast checks for ConstantInt, ConstantFP, and vectors. Seems like a bit of wasted work if we already know we're looking at an integer. |
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
3047 ↗ | (On Diff #193380) | ssubo nodes may be created during ssubsat legalization, so it's possible for nodes of this form to occur during codegen of canonical IR, even after D60061. With that in mind, I think it's okay to have this as a DAG transform as well. isNotMinSignedValue() isn't applicable here as it operates on IR constants. We could replicate the same effect using matchUnaryPredicate() here, if we're interested in parity. |
Indeed. In fact, we see the suboptimal code today when compiling a sadd.with.overflow with the negated constant, so this should be fixed anyway. I've checked the fix in as rev 357597.
If you rebase against that revision, you should no longer see the regression.