This patch adds supports for the vector constant folding of FCEIL, FFLOOR and FTRUNC instructions.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
2848 ↗ | (On Diff #22918) | Yes - x86_mmx registers choke on VT.getVectorElementType() if we don't have the VT.isVector() test to stop them. |
test/CodeGen/X86/vec_floor.ll | ||
228 ↗ | (On Diff #22918) | Yes I should be able to get something to work - probably with explicit hex values though. |
test/CodeGen/X86/vec_floor.ll | ||
---|---|---|
228 ↗ | (On Diff #22918) | I haven't found anything that works yet - do you known of any equivalent values in other tests? I haven't found anything so far. |
I've refreshed this patch after realising that I was being a little over the top with the original implementation:
1 - we no longer need to test for the output type being a vector - this can only occur from the folded unary op being a BITCAST (to a non vector type) and no code path requires BITCASTs to treat the VT as a vector anymore. There are plenty of existing test cases that do this (vec -> mmx, vec -> i64 vec -> i128 are examples I found).
2 - we can safely use the existing scalar path for FCEIL/FFLOOR/FTRUNC ops (and avoid all that functional duplication) - if they do fail to fold they will return a FCEIL/FFLOOR/FTRUNC scalar op which will fail the vector test for a UNDEF/CONSTANT/CONSTANTFP result.
3 - despite various suggestions I've not found any floating point constant that fails on the APFloat roundToIntegral - given the patch now uses the existing scalar path that already thoroughly tests this I think we can safely just use that and just accept that its being very, very cautious. I still wonder if its possible to cause it to fail with more exotic float types but haven't found any examples in the DAGCombine or InstCombine float constant folding tests.