Perform the following transform for shift constants if legal
((X+1) >> ShiftBits) <= NewC -> X < (NewC << ShiftBits) ((X+1) >> ShiftBits) > NewC -> X >= (NewC << ShiftBits)
Differential D121355
[WIP][SelectionDAG] Fold shift constants into cmp Allen on Mar 9 2022, 11:21 PM. Authored by
Details Perform the following transform for shift constants if legal ((X+1) >> ShiftBits) <= NewC -> X < (NewC << ShiftBits) ((X+1) >> ShiftBits) > NewC -> X >= (NewC << ShiftBits)
Diff Detail Event Timeline
Comment Actions @craig.topper please let me know if you have some more idea, thanks
Comment Actions It looks this code works also on arm backend, what I do is only on aarch64.
Comment Actions ARMTargetLowering::getARMCmp and AArch64TargetLowering::getAArch64Cmp both have code that tries to adjust the condition code to get the immediate to fit. So it looks like the primary problem is that introduction of the ISD::SRL that blocks the target from seeing a constant they can fix it. Comment Actions hi, @craig.topper
Comment Actions ping? @craig.topper
Comment Actions I'm not sure I like this patch as is. The fundamental problem isn't directly the shift code. We have conflict between canonicalization and target lowering. Canonicalization prefers to create SET(U)GT/SET(U)LT. But that may create an unsupported constant. Is it the target's responsibility to detect reverse the canonicalization during lowering? We do that already for setgt X, -1 on many targets. ARM and AArch64 do it for even more constant values. Or should canonicalization be consulting isLegalICmpImmediate? If it's the target's responsibility during, then we should just block the shift transform and leave the unsupported immediate so the target can fix it. What we have a right now is somewhere in the middle of these two ideas. We're only considering very specific constants by creating the constant the shift code. But we've made the SETGE/SETUGE canonicalization block transforming a potentially larger set of the constants. Comment Actions I'm a little worried that this is likely to lead to infinite loops with constant/condcode combines fighting - this feels like it should be be backend specific tbh, or maybe even ISelDAGToDAG. Comment Actions I added condition isLegalICmpImmediate on line 4335, which will guard the infinite loops. |
This comment doesn't provide much information to the reader outside of the context of this patch. Can you elaborate for future readers?