llvm dev - Jul 2012 - [LLVMdev] Possible issue with EXPANDING POST-RA PSEUDO INSTRS

Hello everyone, 

  I am running into an obscure issue with ExpandPostRA. Does anyone
recognizes the following:

The pass replaces a real copy with a "transfer" instruction:

********** EXPANDING POST-RA PSEUDO INSTRS **********
********** Function: main
real copy:   %R15<def> = COPY %R4, %D2<imp-use,kill>,
%D7<imp-use,kill>,
%D7<imp-def>
replaced by: %R15<def> = TFR %R4, %D7<imp-def>

The R4 is a subreg of D2 double register (basically R0:R1==D0; R4:R5==D2
etc.). After this copy D2 is dead, and is marked as such.
Register allocator did not mark R4 as <kill>, and when ExpandPostRA copies
operands, it loses the live range marker.

My questions - is this a known issue? ...and should R4 has been marked as
<kill> in the original instruction?

...and yes... I am on branch 3.1, not on trunk, so if it has been fixed by
now, it would be great to know.

Thanks a lot.

Sergei

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.

On Jul 8, 2012, at 3:42 PM, Sergei Larin <slarin at codeaurora.org> wrote:
> ********** EXPANDING POST-RA PSEUDO INSTRS **********
> ********** Function: main
> real copy:   %R15<def> = COPY %R4, %D2<imp-use,kill>,
%D7<imp-use,kill>,
> %D7<imp-def>
> replaced by: %R15<def> = TFR %R4, %D7<imp-def>
> 
> The R4 is a subreg of D2 double register (basically R0:R1==D0; R4:R5==D2
> etc.). After this copy D2 is dead, and is marked as such.
> Register allocator did not mark R4 as <kill>, and when ExpandPostRA
copies
> operands, it loses the live range marker.
> 
> My questions - is this a known issue? ...and should R4 has been marked as
> <kill> in the original instruction?
It's not a bug as such. It is OK for kill flags to be missing.

It's weird that R4 isn't killed out of RA, though. What does it look
like before rewriting? (-debug-only=regalloc).

/jakob

Jakob, 

It looks something like this:

	%vreg15<def> = COMBINE_rr %vreg11, %vreg14<kill>;
DoubleRegs:%vreg15
IntRegs:%vreg11,%vreg14
	%vreg20<def> = CONST32GP_set <ga:@inst3>; IntRegs:%vreg20
	STriw_GP <ga:@inst2+4>, 0, %vreg3<kill>; mem:ST4[getelementptr
inbounds (%struct.myStruct* @inst2, i32 0, i32 1)](tbaa=!"int")
IntRegs:%vreg3
	%vreg28<def> = CONST32GP_set <ga:@inst2>; IntRegs:%vreg28
	%vreg17:subreg_hireg<def> = COPY %vreg15:subreg_loreg<kill>;
DoubleRegs:%vreg17,%vreg15

COMBINE_rr == combine two (32) regs into one (64) pair.

You are seeing whole live range of vreg15.

At this point:
  %vreg17:subreg_hireg<def> = COPY %vreg15:subreg_loreg<kill>;
DoubleRegs:%vreg17,%vreg15

We know that we are killing %vreg15:subreg_loreg, but after Stack Slot
Coloring I got this:

  %R15<def> = COPY %R4, %D2<imp-use,kill>, %D7<imp-use,kill>,
%D7<imp-def>
   

The actual problem happens much later, in post RA scheduler - we use
critical antidependency breaker, and that is messed up by the missing kill.

Thanks for your help.

Sergei

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.

> -----Original Message-----
> From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk]
> Sent: Sunday, July 08, 2012 8:27 PM
> To: Sergei Larin
> Cc: 'List'
> Subject: Re: [LLVMdev] Possible issue with EXPANDING POST-RA PSEUDO
> INSTRS
> 
> 
> On Jul 8, 2012, at 3:42 PM, Sergei Larin <slarin at codeaurora.org>
wrote:
> 
> > ********** EXPANDING POST-RA PSEUDO INSTRS **********
> > ********** Function: main
> > real copy:   %R15<def> = COPY %R4, %D2<imp-use,kill>,
%D7<imp-
> use,kill>,
> > %D7<imp-def>
> > replaced by: %R15<def> = TFR %R4, %D7<imp-def>
> >
> > The R4 is a subreg of D2 double register (basically R0:R1==D0;
> > R4:R5==D2 etc.). After this copy D2 is dead, and is marked as such.
> > Register allocator did not mark R4 as <kill>, and when
ExpandPostRA
> > copies operands, it loses the live range marker.
> >
> > My questions - is this a known issue? ...and should R4 has been
> marked
> > as <kill> in the original instruction?
> 
> It's not a bug as such. It is OK for kill flags to be missing.
> 
> It's weird that R4 isn't killed out of RA, though. What does it
look
> like before rewriting? (-debug-only=regalloc).
> 
> /jakob