In analyzeCompare() function in AArch64InstrInfo.cpp, the return val type of decodeLogicalImmediate is uint64_t, while CmpValue is int, it causes a bug when converting uint64_t to int. The bug was found in spec2006-483.xalancbmk. CmpValue is only used to compare with zero in OptimizeCompareInstr(), so we can fix it by comparing it with zero in analyzeCompare().
Details
Diff Detail
Event Timeline
Shouldn't you be able to produce a test for this? It doesn't seem impossibly difficult to distil the key features from the SPEC case.
I think the change also needs better documentation. You're changing the meaning of CmpValue here: no-one can ever rely on any nonzero value after this commit. That might be OK, since we don't want to anyway right now, but I think it needs to be clear and blow up horribly.
Perhaps making sure CmpValue is always 0 or 1, and asserting that in optimizeCompare? (With an appropriate comments about the limitation and why it was introduced).
Cheers.
Tim.
Test case is added in the new patch. Without the patch, an ANDS instruction will be deleted when doing peephole optimization.
Thanks for the test, but what about the other comments? I still think the code change leaves that area too ambiguous.
Cheers.
Tim.
Yes, This patch changes the meaning of CmpValue. It may not be the best way to solve this problem, but it has no effect on the other compare instructions and other backends comparing to the way of changing the interface of the function. And appropriate comments are added in optimizeCompare.
I have converted all of the CmpValue to 0 or 1, and also added assertion in optimizeCompare. For that our daily performance test have broken down for a long time, please review it ASAP. Thank you!
Thanks David,
I think that looks OK now. Hopefully any future meddlers will notice the warnings.
Cheers.
Tim.