[LLVMdev] Question about post RA scheduler

[Akira Hatanaka]

I filed a bug report (Bug 12205).
Please take a look when you have time.

Per your suggestion, I also attached a patch which attaches to load or
store nodes a machinepointerinfo that points to a stack frame object
when it can infer they are actually reading from or writing to the
stack. The test that was failing passes if I apply this patch, but I
doubt this is the right approach, because this will fail if
InferPointerInfo in SelectionDAG.cpp cannot discover a load or store
is accessing a stack object (it can only infer the information if the
expression for the pointer is simple, for example add FI + const).

An alternative approach might be to make the machinepointerinfo of the
stores refer to %struct.ObjPointStruct* byval %P or refer to nothing,
but that currently doesn't seem to be possible.

On Tue, Mar 6, 2012 at 6:01 PM, Andrew Trick <atrick at apple.com> wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: machineptrinfo.patch
Type: text/x-patch
Size: 1123 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120307/20204c6d/attachment.bin>