For CMP imm instruction, when the operand 1 is symbol address we should
check if it is immediate first. Here is the example code.
CMP64mi32 $noreg, 8, killed renamable $rcx, @d, $noreg, @a, implicit-def $eflags
However I am not able to create a small test case to expose this issue.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thank @lebedev.ri. This is triggered by our internal code, the same test case passes with llvm trunk code. BTW, do you think we need to check immediate before getting it?
llvm/lib/Target/X86/X86InstrInfo.cpp | ||
---|---|---|
6358 | But CMP64mi32 shouldn't go to here. |
It would be nice to have a test, but this change seems ok.
llvm/lib/Target/X86/X86InstrInfo.cpp | ||
---|---|---|
6358 | The CMPmi32 will be expanded to a load and CMPri32. This switches use the opcode after it's expanded. |
LGTM but let's wait one or two days to see opinions from others.
llvm/lib/Target/X86/X86InstrInfo.cpp | ||
---|---|---|
6358 | Thanks Craig. |
It isn't immediately obvious to me how that can happen.
I don't think this should land without a test.
I don't what Intel's original failure looked like, but here's a test that should reproduce this with -run-pass=machinelicm https://reviews.llvm.org/P8267 needs more cleanup.
I hacked the MIR just before machinelicm by sinking the CMP64mi32 and SETCCr into the loop. That makes MachineLICM want to unfold it since the load part is invariant being from a constant global.
Hi Craig,
Awesome. Many thanks for the test case. I applied your test case to this patch.
But CMP64mi32 shouldn't go to here.