search for: hasfp

...en/SystemZ/2009-07-10-BadIncomingArgOffset.ll (See below for the output with this patch.) The problem is that SystemZ is using "hasCalls()" in the back end to determine if a frame pointer is needed or not. My guess is that several of the places where it calls hasCalls() should really be hasFP(). I don't have enough expertise in all of the back ends to determine if the call should be "hasFP" or "hasCalls". I need the respective back end owners to perform an audit of their code. This can be done even before my patch goes in (it's not ready yet). Please look at...

...is line worked well :) Here it is, my first patch to LLVM :) I've changed all allocation_order_begin() and allocation_order_end() methods to take const MachineFunction &MF as a parameter. I also added const version of MachineFunction::getInfo<Ty>() method. And I changed three static hasFP() functions to take const reference to MachineFunction. While doing this I've found that some methods of MachineFunction are const but return non-const pointers to MachineFunction internal info. Is that all right? Thanks, Tony. P.S. I've updated llvm from CVS about 20 hour ago. --------...

On Fri, 6 Oct 2006, [UTF-8] Rafael Esp?ndola wrote: > In ARM the stack should be 8 bytes aligned during function calls. A > function that has at least one function call then has a stack size of > 8 bytes. PEI::calculateFrameObjectOffsets corretly computes this > correctly. > > The problem is that the alignment is computed before adding space for > the call frame size. This is

Hi Chris, > On Wed, 16 Aug 2006, Anton Vayvod wrote: > > I'm willing :) I don't know how to do it. What's "to put together a > > patch"? :) > > In your local CVS tree, change the methods to be const, and adjust any > code that is neccesary for that to work. Once that is done, from the > top level, type 'cvs diff -u >& patch.txt'

...“Target/XYZ/” TargetFrameLowering::determineCalleeSaves() { “CodeGen/” Return <<< some object derived from “*CallingConv.td” >>>; “build/lib/Target/XYX/” } ... SavedRegs.set(Reg); // to “add” a reg, EG for ‘hasFP’, ETC ... } } The SavedRegs set always starts out with a predefined calling-convention value That comes typically from “*CallingConv.td” hence is not function-specific. The only time SavedRegs.reset() is ever called (which is rarely to begin with) are for target-specific, calling-...

In ARM the stack should be 8 bytes aligned during function calls. A function that has at least one function call then has a stack size of 8 bytes. PEI::calculateFrameObjectOffsets corretly computes this correctly. The problem is that the alignment is computed before adding space for the call frame size. This is done in emitProlog. Currently the ARM backend has a bug in that it doesn't align

...e same technique of the PPC backend to avoid add/subs around calls. In the PPC backend we have: ---------------------------------------------------------------------- if (MFI->hasCalls()) { NumBytes += MFI->getMaxCallFrameSize(); } if ((NumBytes == 0) || (NumBytes <= 224 && !HasFP && !MFI->hasCalls() && MaxAlign <= TargetAlign)) { MFI->setStackSize(0); return; } unsigned Align = std::max(TargetAlign, MaxAlign); unsigned GPRSize = 4; unsigned Size = HasFP ? GPRSize + GPRSize : GPRSize; NumBytes = (NumBytes+Size+Align-1)/Align*Align...

...“Target/XYZ/” TargetFrameLowering::determineCalleeSaves() { “CodeGen/” Return <<< some object derived from “*CallingConv.td” >>>; “build/lib/Target/XYX/” } ... SavedRegs.set(Reg); // to “add” a reg, EG for ‘hasFP’, ETC ... } } The SavedRegs set always starts out with a predefined calling-convention value That comes typically from “*CallingConv.td” hence is not function-specific. The only time SavedRegs.reset() is ever called (which is rarely to begin with) are for target-specific, calling-...

...!MFI->hasVarSizedObjects() && // No dynamic alloca. !MFI->adjustsStack() && // No calls. !IsWin64) { // Win64 has no Red Zone uint64_t MinSize = X86FI->getCalleeSavedFrameSize(); if (HasFP) MinSize += SlotSize; StackSize = std::max(MinSize, StackSize > 128 ? StackSize - 128 : 0); MFI->setStackSize(StackSize); } else if (IsWin64) { // We need to always allocate 32 bytes as register spill area. // FIXME: We might reuse these 32 bytes for leaf functions. Stac...

...:) > Here it is, my first patch to LLVM :) > I've changed all allocation_order_begin() and allocation_order_end() methods > to take const MachineFunction &MF as a parameter. I also added const version > of MachineFunction::getInfo<Ty>() method. And I changed three static hasFP() > functions to take const reference to MachineFunction. Looks great, applied: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060814/036832.html ... http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060814/036839.html > While doing this I've found that some...

Hi Chris, >> It is marked callee saved. Because when it is not needed as frame >> pointer it is used like an ordinary register. But when it is used as >> frame pointer, the prologue and epilogue change its value, but the >> algorithm in llvm that finds clobbered register does not select it. >> > > Okay, I'm not sure. If you describe the constraints

...sTarget64BitLP64() || STI.isTargetNaCl64(); StackPtr = TRI->getStackRegister(); + SaveArgs = STI.getSaveArgs(); } bool X86FrameLowering::hasReservedCallFrame(const MachineFunction &MF) const { @@ -83,7 +84,7 @@ /// or if frame pointer elimination is disabled. bool X86FrameLowering::hasFP(const MachineFunction &MF) const { const MachineFrameInfo &MFI = MF.getFrameInfo(); - return (MF.getTarget().Options.DisableFramePointerElim(MF) || + return (MF.getTarget().Options.DisableFramePointerElim(MF) || SaveArgs || TRI->needsStackRealignment(MF) || MFI...

...nst X86MachineFunctionInfo *MFI = MF.getInfo<X86MachineFunctionInfo>(); // Does the function dedicate RBP / EBP to being a frame ptr? if (!Subtarget.is64Bit()) // In 32-mode, none of the 8-bit registers aliases EBP or ESP. return begin() + 8; else if (TFI->hasFP(MF) || MFI->getReserveFP()) // If so, don't allocate SPL or BPL. return array_endof(X86_GR8_AO_64) - 1; else // If not, just don't allocate SPL. return array_endof(X86_GR8_AO_64); } }]; } It is inconvenient to compute the front and back of the...

On Mar 28, 2008, at 5:17 PM, Chuck Rose III wrote: > I was curious about the state of stack alignment on x86. I noticed > there are a few bugs outstanding on the issue. I recently added > some code which had the effect of throwing an extra function > parameter on our stack at runtime, a 4 byte pointer. > > Esp is now not 16-byte aligned, so instructions like unpcklps

Hola LLVMers, I was curious about the state of stack alignment on x86. I noticed there are a few bugs outstanding on the issue. I recently added some code which had the effect of throwing an extra function parameter on our stack at runtime, a 4 byte pointer. Esp is now not 16-byte aligned, so instructions like unpcklps xmm1, dword ptr [eps] cause grief. My AllocaInstr instructions are

Mehdi, I am looking for an understanding of 1) IPRA in general, 2) IPRA in LLVM. Whether I want to use LTO or not is a separate issue. 1) I currently believe it is a true statement that: If all external functions are known to not call back into the “whole-program” Being compiled, then IPRA is free to do anything at all to the functions being