This patch adds supports for the vector constant folding of FCEIL, FFLOOR and FTRUNC instructions.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
test/CodeGen/X86/vec_floor.ll | ||
---|---|---|
228 | 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.
Naive question: Is it possible to have a BuildVector without a VT for a vector?