search for: spillcalleesavedregisters

...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 inst...

...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. >> &g...

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

On Mon, Mar 2, 2009 at 10:35 AM, Evan Cheng <echeng at apple.com> wrote: > > On Mar 1, 2009, at 2:57 PM, John Mosby wrote: > > Obviously, all of this applies only when spills are done with push/pop, > which is the case on x86. I used this issue to start looking at generalizing > how spills and restores are handled, before looking too closely at other > targets, and

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