search for: spillcalleesavedregister

...obust way to go about things. I haven't fully traced through where the flag is used in LLVM, but it does seem that DwarfDebug::findPrologueEndLoc will return the wrong result if the flag isn't consistently set on frame setup code. The problem is that unless you override TargetFrameLowering::spillCalleeSavedRegisters, then PrologEpilogInserter will just spill callee saved registers through a series of calls to storeRegToStackSlot. This is fine, except storeRegToStackSlot won't set the FrameSetup flag. [1]: Actually X86 will only skip over PUSH instructions with the FrameSetup flag. Is this extra condition...

...r any CSR (this is done by the "Offset = MaxOffset - Offset + saveAreaOffset;" line). Is there a reason why llvm doesn't keep around the offsets in the right order from very beginning, by pushing the CSRs in increasing order of FrameIdxs? [1]: in fact, the way X86FrameLowering's spillCalleeSavedRegisters and PEI's calculateCalleeSavedRegisters are set up, I don't see a reason why the FrameIdxs and the generated push instructions have any relation at all. It seems that the code relies on MFI->CreateStackObject returning sequential integers. Thanks! -- Sanjoy

...d through > where > > the flag is used in LLVM, but it does seem that > DwarfDebug::findPrologueEndLoc > > will return the wrong result if the flag isn't consistently set on frame > setup > > code. The problem is that unless you override > > TargetFrameLowering::spillCalleeSavedRegisters, then > PrologEpilogInserter will > > just spill callee saved registers through a series of calls to > > storeRegToStackSlot. This is fine, except storeRegToStackSlot won't set > the > > FrameSetup flag. > > > > [1]: Actually X86 will only skip over PUSH ins...

...that checking out some old experimental code to solve this, it also seems to require to reversing the order of XMM/YMM registers within calling convention definitions in X86CallingConv.td, and to do other minor changes to account for these. >> [1]: in fact, the way X86FrameLowering's spillCalleeSavedRegisters and >> PEI's calculateCalleeSavedRegisters are set up, I don't see a reason >> why the FrameIdxs and the generated push instructions have any >> relation at all. It seems that the code relies on >> MFI->CreateStackObject returning sequential integers. >> &...

Hi, Target overrides of processFunctionBeforeFrameFinalized() are misused in two cases (MBlaze and PowerPC) to set the offsets of objects. Unfortunately this has no effect because the offsets are immediately reset by calculateFrameObjectOffsets(). The PowerPC backend does this to setup the stack frame layout according to the ABI. Ie. it spills the registers etc. in a fixed layout. How to do

...architecture I am looking at. > > > It's not necessary to update all the targets at once. We can ask targets to > opt in to take advantage of shrink wrapping. > That sounds good. I now have a better handle on the differences between the targets: XCore handles frame moves in its spillCalleeSavedRegister(), the ARM code for this is very straightforward. I hope to have an updated patch done tomorrow, with doc. and explicated examples. Thanks, John -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090302/aa0798...

On Mar 1, 2009, at 2:57 PM, John Mosby wrote: > First, thanks very much for your comments! > > On Sat, Feb 28, 2009 at 8:05 PM, Evan Cheng <evan.cheng at apple.com> > wrote: > > On Feb 26, 2009, at 2:02 PM, John Mosby wrote: > > It is limited to X86 presently since that is the only target I have > > access to at the moment. > > What part of this is

First, thanks very much for your comments! On Sat, Feb 28, 2009 at 8:05 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 26, 2009, at 2:02 PM, John Mosby wrote: > > It is limited to X86 presently since that is the only target I have > > access to at the moment. > > What part of this is target dependent? Is this due to emitPrologue / > emitEpilogue being