[LLVMdev] Patch - big stackframes on SPU
Raiskila Kalle
kalle.raiskila at nokia.com
Fri Feb 26 02:25:38 PST 2010
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>
More information about the llvm-dev
mailing list