This also removes a pattern from RISCV that is no longer needed
since the sexti32 on the LHS of the srem in the pattern implies
the result is sign extended so the sign_extend_inreg should be
removed in DAG combine now.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
3877 | This is a lot more relaxed than ValueTracking ? |
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
3877 | Interesting! ValueTracking seems to abort on !Denominator->isStrictlyPositive(). When I reviewed the logic of this code at first I thought there would be cases where it would break, but when I thought about it more deeply it all seemed fine. Now I'm curious about what may explain the divergence. Maybe the implementation in ValueTracking was considering modulus instead of remainder? |
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
3877 | The implementation in value tracking only handles constant right hand side. Looking at the history, its original implementation was incorrect and maybe thought the result was always positive at least from the the original comment. I didn't handle constant here because I figured most targets would expand an srem by constant using BuildSDIV in TargetLowering. |
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
3877 | It might make sense to update ValueTracking to hanldle the non-constant case. Some experiments I did from C seemed to get helped by CorrelatedValuePropagation. For example a shl after an srem with extra sign bits can pick up an nsw flag through CVP. This allows InstSimplify/InstCombine to late remover a shl+ashr sign extend pair due to the nsw. |
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
3877 | That sounds like a great followup but I'm happy for this to go ahead independently. Thanks for looking into this. |
This is a lot more relaxed than ValueTracking ?