[PATCH] D35985: Skip live range segment verification for reserved physregs
Stefan Maksimovic via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jul 28 03:32:28 PDT 2017
smaksimovic added a comment.
Test where this was spotted is `test/CodeGen/Mips/no-odd-spreg-msa.ll` which fails when checked with machine verifier on.
What exactly happens is that a value is moved from a physical register which is not reserved($f12) to a physical register which
in this case is($f13) via inline asm.
...
64B INLINEASM <es:mov.s $0, $1> [sideeffect] [attdialect], $0:[regdef], %F13<imp-def>, $1:[reguse], %F12
80B %vreg2<def> = COPY %F13; FGR32:%vreg2
96B %vreg3<def> = LW %vreg1, <ga:@v4f32>[TF=1]; mem:LD4[GOT] GPR32:%vreg3,%vreg1
112B %vreg4<def> = LD_W %vreg3, 0; mem:Volatile LD16[@v4f32](dereferenceable) MSA128W:%vreg4 GPR32:%vreg3
128B %vreg8<def> = SUBREG_TO_REG 0, %vreg2, sub_lo; MSA128WEvens:%vreg8 FGR32:%vreg2
...
The reserved one is an operand of a COPY instruction which will later get evicted after register coalescing.
...
80B %vreg2<def> = COPY %F13; FGR32:%vreg2
Considering merging %vreg2 with %F13
RHS = %vreg2 [80r,128r:0) 0 at 80r
updated: 128B %vreg8<def> = SUBREG_TO_REG 0, %F13, sub_lo; MSA128WEvens:%vreg8
Success: %vreg2 -> %F13
Result = %F13
...
After merging:
...
64B INLINEASM <es:mov.s $0, $1> [sideeffect] [attdialect], $0:[regdef], %F13<imp-def>, $1:[reguse], %F12
96B %vreg3<def> = LW %vreg1, <ga:@v4f32>[TF=1]; mem:LD4[GOT] GPR32:%vreg3,%vreg1
112B %vreg5<def> = LD_W %vreg3, 0; mem:Volatile LD16[@v4f32](dereferenceable) MSA128W:%vreg5 GPR32:%vreg3
128B %vreg8<def> = SUBREG_TO_REG 0, %F13, sub_lo; MSA128WEvens:%vreg8
...
The problem here is that the https://reviews.llvm.org/F13 regunit does not get its intervals updated and the error is emitted in MachineVerifier::verifyLiveRangeSegment
in the block which reports "Live segment doesn't end at a valid instruction" error message, due to non-existing instuction at live segment end.
`F13 [64r,80r:0) 0 at 64r`
I've searched for information on handling live ranges of physical registers, particularly reserved ones and found this:
http://lists.llvm.org/pipermail/llvm-dev/2016-February/095999.html
and came to the conclusion that reserved physical registers are assumed always live hence their live segments shouldn't be taken into consideration
since they aren't updated properly as can be seen from the output above.
https://reviews.llvm.org/D35985
More information about the llvm-commits
mailing list