Reenable post-legalize stores with constant merging computation and corresponding test case.
Details
Diff Detail
- Build Status
Buildable 12723 Build 12723: arc lint + arc unit
Event Timeline
llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
12712 ↗ | (On Diff #125131) | This isn't what a "truncating" store means for floating-point values. It converts the value using ISD::FP_ROUND. (We use nodes like this to model something like an x87 fstps; not sure if any other target uses it.) |
llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
12712 ↗ | (On Diff #125131) | Does it mean such stores should not be merged? |
llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
12712 ↗ | (On Diff #125131) | We can still merge them... we just have to call APFloat::convert() to narrow the value to the right size, as opposed to an integer truncate. Or I guess we could just blacklist float truncstores. |
llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
12712 ↗ | (On Diff #125131) | Hmm, the original code was StoreInt |= C->getValueAPF().bitcastToAPInt().zext(SizeInBits); In r303802 Nirav changed it into the version on left. The commit comment is
According to your comment truncating can destroy the value. So the commit was not NFC. |
Nirav,
There are stability and correctness issues on AArch64. The similar issues might exist on other ARM targets. Could you please disable MergeConsecutiveStores for all ARM targets including AArch64?
Thanks,
Evgeny
llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
12712 ↗ | (On Diff #125131) | Eli: Is that right? Looking at LegalizeDAG, when we expand a TruncStore we do it as a store of a truncate which IIUC is strictly bitvector-level interpretation. |
I've disable store merges of FP constants with truncation as it's not clear what is the right behavior at the moment.
Evgeny, can you please test that this works for you?
Looking at LegalizeDAG, when we expand a TruncStore we do it as a store of a truncate which IIUC is strictly bitvector-level interpretation.
Yes, the LegalizeDAG code will likely crash on a float TruncStore (but they don't show up outside of x86, so probably nobody noticed). But the intent is pretty clear if you look at how the x86 backend lowers them. There's also a comment in SelectionDAGNodes.h. But anyway, it's obscure enough that it probably doesn't matter if you disable the optimization.
Weird. Post-legalized store for X86 has been turned on since early August. I'm surprised we didn't run into a bug sooner.
Hi Nirav,
This patch passed AArch64 NEON Emperor tests but it crashes on the test case reduced from spec2k6.
Thanks,
Evgeny
I don't think I've seen that one. Can you send that test case to me so I can reproduce it?
$ llc -O3 test_crash.ll llc: /home/llvm-test/tmp/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1002: void (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode *): Assertion `(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || TLI.isTypeLegal(Op.getValueType()) || Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Register) && "Unexpected illegal type!"' failed. ...
AArch64 failing case is failing because we did not check that constucted BUILD_VECTOR elements were legal.
Add test case and fix.
For completeness/reference, I'm linking to D40790 which includes a failure test for SystemZ. It looks very similar to test/CodeGen/ARM/arm-storebytesmerge.ll, so I'm not sure if it adds value to have another target included in the tests when this is committed, but I thought I'd mention it here.