search for: spillcalleesavedregist

Displaying 8 results from an estimated 8 matches for "spillcalleesavedregist".

2017 Feb 17
7
RFC: Setting MachineInstr flags through storeRegToStackSlot
...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 conditi...
2014 May 27
3
[LLVMdev] Question about callee saved registers in x86
...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
2017 Feb 21
3
RFC: Setting MachineInstr flags through storeRegToStackSlot
...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 i...
2014 May 30
2
[LLVMdev] Question about callee saved registers in x86
...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. >>...
2012 Aug 06
1
[LLVMdev] processFunctionBeforeFrameFinalized setting object offset without effect, stack frame layout wrong
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
2009 Mar 03
2
[LLVMdev] Shrink Wrapping - RFC and initial implementation
...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/aa07...
2009 Mar 02
0
[LLVMdev] Shrink Wrapping - RFC and initial implementation
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
2009 Mar 01
2
[LLVMdev] Shrink Wrapping - RFC and initial implementation
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