[llvm-commits] [llvm] r141859 - in /llvm/trunk: lib/Target/X86/X86FrameLowering.cpp test/CodeGen/X86/segmented-stacks.ll

[Evan Cheng]

I don't think isel is right place to implement this kind of low level optimization.

Evan

On Oct 13, 2011, at 12:54 PM, Duncan Sands wrote:

> Hi Jakob,
> 
>>> More closely follow libgcc, which has code after the `ret' instruction to
>>> release the stack segment and reset the stack pointer. Place the code in its own
>>> MBB to make the verifier happy.
>> 
>> Wait, what?
>> 
>> Is the verifier happy with a return block with successors? That sounds like a bug ;)
>> 
>> Seriously, though. What is going on here? I am worried that branch folding doesn't understand this, and rearranges the blocks.
> 
> Sanjoy sent me the following explanation of why code is added after the "ret":
> 
> This is dictated by libgcc.  Here is the relevant comment from
> libgcc/config/i386/morestack.S:
> 
> # We do a little dance so that the processor's call/return return
> # address prediction works out.  The compiler arranges for the caller
> # to look like this:
> #   call __generic_morestack [ typo in libgcc, should be _morestack]
> #   ret
> #  L:
> #   // carry on with function
> # After we allocate more stack, we call L, which is in our caller.
> # When that returns (to the predicted instruction), we release the
> # stack segment and reset the stack pointer.  We then return to the
> # predicted instruction, namely the ret instruction immediately after
> # the call to __generic_morestack.  That then returns to the caller of
> # the original caller.
> 
> Ciao, Duncan.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits