[MIR-Canon] Hardening propagateLocalCopies. - If there is no register class for a COPY's src or dst, bail. - Fixes uses iterator clobbering bug.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/CodeGen/MIRCanonicalizerPass.cpp | ||
---|---|---|
345 | Because in some cases like: %namedVReg4353:sreg_32_xm0 = S_MOV_B32 0 %namedVReg1352:vgpr_32 = COPY %namedVReg4353 ... BUFFER_STORE_DWORD_ADDR64 %namedVReg1352, %namedVReg1353, %namedVReg1354, 0, 0, 0, 0, 0, 0, implicit $exec Folding the copy causes a verifier error even though the types are the same: %namedVReg4353:sreg_32_xm0 = S_MOV_B32 0 ... BUFFER_STORE_DWORD_ADDR64 %namedVReg4353:sreg_32_xm0, %namedVReg1353:vreg_64, %namedVReg1354:sgpr_128, 0, 0, 0, 0, 0, 0, implicit $exec S_ENDPGM 0 *** Bad machine code: Illegal virtual register for instruction *** - function: foo - basic block: %bb.0 (0x559c6b1fa878) - instruction: BUFFER_STORE_DWORD_ADDR64 %namedVReg4353:sreg_32_xm0, %namedVReg1353:vreg_64, %namedVReg1354:sgpr_128, 0, 0, 0, 0, 0, 0, implicit $exec - operand 0: %namedVReg4353:sreg_32_xm0 Expected a VGPR_32 register, but got a SReg_32_XM0 register LLVM ERROR: Found 1 machine code errors. I think the right way is only to fold on matching types if regbankselect has not happened (in the case where there is no register class), which I will probably add in a different commit. |
I'm seeing intermittent failures locally for this test on macOS since this was committed, and that seems confirmed by this bot:
http://green.lab.llvm.org/green/blue/organizations/jenkins/clang-stage1-cmake-RA-incremental/activity
(click 'Show More' at the bottom to extend the history and see this test as the only toggling failure with seemingly random NFC changes)
When it fails, the verbose output says something like this:
: 'RUN: at line 1'; /Users/spatel/GitHub/llvm-project/release/bin/llc -o - -march=amdgcn -run-pass mir-canonicalizer -x mir /Users/spatel/GitHub/llvm-project/llvm/test/CodeGen/MIR/AMDGPU/mir-canon-multi.mir | /Users/spatel/GitHub/llvm-project/release/bin/FileCheck /Users/spatel/GitHub/llvm-project/llvm/test/CodeGen/MIR/AMDGPU/mir-canon-multi.mir -- Exit Code: 1 Command Output (stderr): -- /Users/spatel/GitHub/llvm-project/llvm/test/CodeGen/MIR/AMDGPU/mir-canon-multi.mir:5:15: error: CHECK-NEXT: is not on the line after the previous match # CHECK-NEXT: %namedVReg1358:vgpr_32 = COPY %namedVReg1361 ^ <stdin>:77:2: note: 'next' match was here %namedVReg1358:vgpr_32 = COPY %namedVReg1361 ^ <stdin>:75:46: note: previous match ended here %namedVReg1352:vgpr_32 = COPY %namedVReg4353 ^ <stdin>:76:1: note: non-matching line after previous match is here %namedVReg1353:vreg_64 = REG_SEQUENCE %namedVReg4354, %subreg.sub0, %namedVReg1352, %subreg.sub1
Very strange that the non-determinism is introduced after fixing the iterator invalidation. I will investigate and put something together tomorrow.
Can you explain why the type along isn't sufficient