[LLVMdev] Question about post RA scheduler

Andrew Trick atrick at apple.com
Tue Mar 6 18:01:44 PST 2012


On Mar 6, 2012, at 5:05 PM, Akira Hatanaka <ahatanak at gmail.com> wrote:
> I am having trouble trying to enable post RA scheduler for the Mips backend.
> 
> This is the bit code of the function I am compiling:
> 
> (gdb) p MF.Fn->dump()
> 
> define void @PointToHPoint(%struct.HPointStruct* noalias sret
> %agg.result, %struct.ObjPointStruct* byval %P) nounwind {
> entry:
>  %res = alloca %struct.HPointStruct, align 8
>  %x2 = bitcast %struct.ObjPointStruct* %P to double*
>  %0 = load double* %x2, align 8
> 
> The third instruction is loading the first floating point double of
> structure %P which is being passed by value.
> 
> This is the machine function right after completion of isel:
> (gdb) p MF->dump()
> # Machine code for function PointToHPoint:
> Frame Objects:
>  fi#-1: size=48, align=8, fixed, at location [SP+8]
>  fi#0: size=32, align=8, at location [SP]
> Function Live Ins: %A0 in %vreg0, %A2 in %vreg1, %A3 in %vreg2
> 
> BB#0: derived from LLVM BB %entry
> 	SW %vreg2, <fi#-1>, 4; mem:ST4[FixedStack-1+4] CPURegs:%vreg2
> 	SW %vreg1, <fi#-1>, 0; mem:ST4[FixedStack-1](align=8) CPURegs:%vreg1
> 	%vreg3<def> = COPY %vreg0; CPURegs:%vreg3,%vreg0
> 	%vreg4<def> = LDC1 <fi#-1>, 0; mem:LD8[%x2] AFGR64:%vreg4
> 
> 
> The first two stores write the values in argument registers $6 and $7
> to frame object -1
> (Mips stores byval arguments passed in registers to the stack).
> The fourth instruction LDC1 loads the value written by the first two
> stores as a floating point double.
> 
> This is the machine function just before post RA scheduling:
> (gdb) p MF.dump()
> # Machine code for function PointToHPoint:
> Frame Objects:
>  fi#-1: size=48, align=8, fixed, at location [SP+8]
>  fi#0: size=32, align=8, at location [SP-32]
> Function Live Ins: %A0 in %vreg0, %A2 in %vreg1, %A3 in %vreg2
> 
> BB#0: derived from LLVM BB %entry
>    Live Ins: %A0 %A2 %A3
> 	%SP<def> = ADDiu %SP, -32
> 	PROLOG_LABEL <MCSym=$tmp0>
> 	SW %A3<kill>, %SP, 44; mem:ST4[FixedStack-1+4]
> 	SW %A2<kill>, %SP, 40; mem:ST4[FixedStack-1](align=8)
> 	%D0<def> = LDC1 %SP, 40; mem:LD8[%x2]
> 
> 
> The frame index operands of the first two stores and the fourth load
> have been lowered to real addresses.
> Since the first two SWs store to ($sp + 44) and  ($sp + 40), and
> instruction LDC1 loads from ($sp + 40),
> there should be a dependency between these instructions.
> 
> However, when ScheduleDAGInstrs::BuildSchedGraph(AliasAnalysis *AA)
> builds the schedule graph,
> there are no dependency edges added between the two SWs and LDC1 because
> getUnderlyingObjectForInstr returns different objects for these instructions:
> 
> underlying object of SWs: FixedStack-1
> underlying object of LDC1: struct.ObjPointStruct* %P
> 
> 
> Is this a bug?
> Or are there ways to tell BuildSchedGraph it should add dependency edges?

This is a wild guess. But it looks to me like your load's machineMemOperand should have been converted to refer to the stack frame. I would call that an ISEL bug. I can't say where the bug is without stepping through a test case.

Maybe someone who's worked in this area of ISEL can give you a better hint. In the meantime, I would file a PR.

-Andy



More information about the llvm-dev mailing list