This simple optimization has been split out of https://reviews.llvm.org/D30400
Details
- Reviewers
rengolin jmolloy efriedma - Commits
- rG3fa5fd1dd278: [Thumb1] Fix the bug when adding/subtracting -2147483648
rGbf19d4bc298e: [Thumb1] combine ADDC/SUBC with a negative immediate
rL297820: [Thumb1] Fix the bug when adding/subtracting -2147483648
rL297682: [Thumb1] combine ADDC/SUBC with a negative immediate
Diff Detail
- Repository
- rL LLVM
Event Timeline
Can you make sure this works with inline asm? We had a trick in the to make it work (Linux stuff), so I just want to make sure it follows the same path on both cases.
Can you make sure this works with inline asm? We had a trick in the to make it work (Linux stuff)
Can you suggest a test case? I'm not quite sure how ADDC/SUBC, inline asm, and Linux all relate to each other.
Right, sorry, this has nothing to do with the assembler, and is only to perform better codegen. Ignore my comments. LGTM. Thanks!
This patch needs to be reverted or appended. I'll try to send a test case.
llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp | ||
---|---|---|
9671 | There's a corner case when imm is -2147483648, that's -2^31 and 0x80000000 in two's compliment. SignExt this value and flip its sign in int64_t, it's still 0x80000000 and interpreted as -2^31 by i32 type. So we have infinite loop here where this function consume and produce the same node forever. |
This test case reproduce the problem (infinite compile time)
define i64 @f6(i64 %x, i64 %y) {
entry:
%tmp1 = add i64 %y, -2147483648 ; <i64> [#uses=1] ret i64 %tmp1
}
There's a corner case when imm is -2147483648, that's -2^31 and 0x80000000 in two's compliment.
SignExt this value and flip its sign in int64_t, it's still 0x80000000 and interpreted as -2^31 by i32 type.
So we have infinite loop here where this function consume and produce the same node forever.