If shift amount is a constant value > 64 bit it is handled incorrectly during type legalization and X86 lowering. This patch the type of shift amount argument in function DAGTypeLegalizer::ExpandShiftByConstant from unsigned to APInt.
Details
- Reviewers
RKSimon nadav majnemer sanjoy - Commits
- rGd1b818bcf414: Reapply fixed r241790: Fix shift legalization and lowering for big constants.
rGeb122f2baf48: Fix shift legalization and lowering for big constants.
rL241806: Reapply fixed r241790: Fix shift legalization and lowering for big constants.
rL241790: Fix shift legalization and lowering for big constants.
Diff Detail
Event Timeline
I don't see anything wrong with the change, but I don't understand the ins and outs (no pun intended!) of SelectionDAG well enough to give an explicit LGTM.
Ok, thanks, I will wait some more.
The change is not much about SelectionDAG. I just want to avoid calling getZExtValue() at line 2180 when the value of the APInt cannot fit 64 bits.
However, I would be very happy if I could commit that before 3.7 release is branched.
Hi Paweł - comments below.
lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp | ||
---|---|---|
2175 | I'm not sure about this - ExpandShiftByConstant already handles shift amounts out of range, setting the result to zero/signbit for logical/arithmetic shifts instead of undef. I think it better to change ExpandShiftByConstant shift amount to take an APInt type instead of an unsigned and update its handling to compare using APInt. If you want to make a case for returning undef for constant shift results it should be in a separate patch. | |
test/CodeGen/X86/legalize-shl-vec.ll | ||
4 | It would be better if these tests checked the resultant codegen, rather than just test for a crash. |
I changed DAGTypeLegalizer::ExpandShiftByConstant to accept APInt as the shift amount.
There is one quirk in that: because there is not operator- for pair (uint64_t, APInt)
I workarounded it with strage looking -Amt + NVTBits.
I'm not sure about this - ExpandShiftByConstant already handles shift amounts out of range, setting the result to zero/signbit for logical/arithmetic shifts instead of undef.
I think it better to change ExpandShiftByConstant shift amount to take an APInt type instead of an unsigned and update its handling to compare using APInt.
If you want to make a case for returning undef for constant shift results it should be in a separate patch.