[LLVMdev] Question about ExpandPostRAPseudos.cpp

Jakob Stoklund Olesen stoklund at 2pi.dk
Thu Jul 26 15:21:02 PDT 2012


On Jul 26, 2012, at 2:37 PM, "Gurd, Preston" <preston.gurd at intel.com> wrote:

> When trying to run test/CodeGen/X86/liveness-local-regalloc.ll with the command line options “-optimize-regalloc=0 –verify-machineinstrs –mcpu-atom”, the test fails right after the Post-RA pseudo instruction pass with the messages
>  
> *** Bad machine code: Using an undefined physical register ***
> - function:    autogen_SD24657
> - basic block: BB 0x2662d60 (BB#0)
> - instruction: %XMM0<def> = MOV64toPQIrr %RAX<kill>
> - operand 1:   %RAX<kill>
> LLVM ERROR: Found 1 machine code errors.
>  
> This happens because, on entry to the pass, we have
>  
> %RAX<def> = SUBREG_TO_REG 0, %R9D, 4
>                %XMM0<def> = MOV64toPQIrr %RAX<kill>
>  
> The pass converts (around about line 132 in ExpandPostRAPseudos.cpp) the SUBREG_TO_REG pseudo op to
>  
>                %EAX<def> = MOV32rr %R9D
>  
> Because of “-mcpu-atom”, post RA scheduling is enabled,  so is post RA liveness tracking. Because the destination has been changed to EAX from RAX in transforming the SUBREG_TO_REG pseudo op into a MOV32rr, liveness checking fails in MachineVerifier.cpp.
>  
> Would anyone be able to comment on why the SUBREG_TO_REG conversion changes the destination register and/or to suggest how this problem might best be fixed?

The SUBREG_TO_REG instruction is like a copy, but it is asserting that the high part of the register was cleared by the defining instruction.

It is normally coalesced away by the optimizing register allocator pipeline, but it can sometimes survive to ExpandPostRAPseudos. The def of %RAX should have been preserved as an implicit def operand on the copy:

               %EAX<def> = MOV32rr %R9D, %RAX<imp-def>

It looks like LowerSubregToReg() needs to Copy->addRegisterDefined(DstReg).

/jakob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120726/c9f68565/attachment.html>


More information about the llvm-dev mailing list