llvm dev - Feb 2010 - [LLVMdev] Patch - big stackframes on SPU

Hello all,

currently the SPU backend does not handle big stack frames (>16*511
bytes) nicely. llc asserts on malformed machine instructions.
(Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr
first
operand is not immediate")

E.g. the function:
define i32 @foo() nounwind {
entry:
    %retval = alloca i32
    %big_data = alloca [1000 x i32]
    store i32 3840, i32* %retval, align 4
    br label %return

return:
    %retval2 = load i32* %retval
    ret i32 %retval2
}
demonstrates this issue.


Attached is a patch to fix this. It
-fixes a few small errors in function prologue and epilogue insertion
-enables register scavenging for frame index elimination
and
- implements the frame index elimination for big stacks.

Patch is made against latest svn head.


best regards,
Kalle Raiskila
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spu_stackframes.patch
Type: text/x-patch
Size: 5333 bytes
Desc: spu_stackframes.patch
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100222/018d292f/attachment.bin>

On Feb 22, 2010, at 6:08 AM, Kalle.Raiskila at nokia.com wrote:
> Hello all,
> 
> currently the SPU backend does not handle big stack frames (>16*511
> bytes) nicely. llc asserts on malformed machine instructions.
> (Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr
first
> operand is not immediate")
Sounds fine to me in general.  Please write a testcase for this though.  Also,
this patch causes the CodeGen/CellSPU/call.ll regression test to fail.  Please
investigate and send an updated patch (with a testcase), thanks!

-Chris
 
> 
> E.g. the function:
> define i32 @foo() nounwind {
> entry:
>    %retval = alloca i32
>    %big_data = alloca [1000 x i32]
>    store i32 3840, i32* %retval, align 4
>    br label %return
> 
> return:
>    %retval2 = load i32* %retval
>    ret i32 %retval2
> }
> demonstrates this issue.
> 
> 
> Attached is a patch to fix this. It
> -fixes a few small errors in function prologue and epilogue insertion
> -enables register scavenging for frame index elimination
> and
> - implements the frame index elimination for big stacks.
> 
> Patch is made against latest svn head.
> 
> 
> best regards,
> Kalle Raiskila
>
<spu_stackframes.patch>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Chris Lattner skrev:
> On Feb 22, 2010, at 6:08 AM, Kalle.Raiskila at nokia.com wrote:
>> currently the SPU backend does not handle big stack frames (>16*511
>>  bytes) nicely. llc asserts on malformed machine instructions. 
>> (Assertion `MI->getOperand(OpNo).isImm() &&
"printDFormAddr first
>> operand is not immediate")
> 
> Sounds fine to me in general.  Please write a testcase for this
> though.  
Attached.

> Also, this patch causes the CodeGen/CellSPU/call.ll
> regression test to fail.
Oops. Sorry about that. I promise to inspect output of 'make check' more
thoroughly in the future.
This is now discussed in this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-February/029706.html


But the CodeGen/CellSPU/call.ll is not the only one that fails. Three 
other tests from CodeGen/CellSPU fail also. The cause of these is the 
enabling of the register scavenger. It allocates the emergency spill 
slot from the stack, and in doing so function prologue and epilogue gets 
injected into some functions that do not use stack at all and thus 
wouldn't have a prologue or epilogue in the first place. (Seems that all 
test case failures are due to this - not bad code or asserts). But 
inserting redundant code ofcourse bloats the generated code...

Would it be possible to conditionally enable the register scavenger only 
if the function has a big stack? It now gets unconditionally enabled in 
  SPURegisterInfo::requiresRegisterScavenging(const MachineFunction &MF).
Just checking MF.getFrameInfo()->getStackSize() here doesn't seem to be 
the solution...


kalle

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bigstack.ll
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100226/2e97950d/attachment.ksh>