search for: calculateframeobjectoffset

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 the new stack. Fixing this bug is simple, but it introduces an inefficiency du...

...ALLSTACK instructions is used to set up MaxCallFrameSize. Adding debug prints also show that in the example code the ADJCALLSTACK argument is 4. I believe that this is the correct argument for only a 32bit integer is passed on the stack. The problem is that MaxCallFrameSize is **not** used in PEI::calculateFrameObjectOffsets and it must then be used in the target specific code. The only architecture that doesn't adds MaxCallFrameSize to the value returned by getStackSize is Sparc. This is so because the Sparc backend generates add/sub pairs around call sites. > Further, you *do* need to have a frame pointer if...

Hello, the calculateFrameObjectOffsets methods in CodeGen/PrologEpilogEmitter.cpp does not work for me, since it asserts if stack grows up, and when assert is commented out, allocates spill slots in the same location as function arguments, which is not right. I've tried to fix that, and a patches. It merely adds if (StackG...

I would like a customized version of the function PEI::calculateFrameObjectOffsets() in PrologEpilogInserter.cpp. What is the clean way to do this?

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 done in emitProlog. Currently the ARM > backend has a bug in that it doesn't align the new stack. This sounds like the ADJCALLSTACK DOWN/...

On Sat, 7 Oct 2006, [UTF-8] Rafael Esp?ndola wrote: >> This sounds like the ADJCALLSTACK DOWN/UP 'instructions' around the call >> aren't set right, or you have declared a SP offset. It doesn't look like >> the ARM backend does this, so this is probably the problem. > The ARM backend currently doesn't use a frame pointer. It uses the > same technique

> This sounds like the ADJCALLSTACK DOWN/UP 'instructions' around the call > aren't set right, or you have declared a SP offset. It doesn't look like > the ARM backend does this, so this is probably the problem. The ARM backend currently doesn't use a frame pointer. It uses the same technique of the PPC backend to avoid add/subs around calls. In the PPC backend we

...rgency spill slot is needed. Since processFunctionBeforeCalleeSavedScan is called before it is known which callee-saved registers need to be spilled, the targets decide whether the spill slot is needed without knowing the exact stack frame size. It seems to me that it would be better to wait until calculateFrameObjectOffsets computes the exact stack size to make the decision and redo the stack size calculation only if the spill slot is needed. bool PEI::runOnMachineFunction(MachineFunction &Fn) { ... TFI->processFunctionBeforeCalleeSavedScan(Fn, RS); ... calculateCalleeSavedRegisters(Fn); ... calcu...

...set. Based on prior discussion this should mean that the local area starts and address ESP+4. Is this really true? On X86 stack grows down, so I'd expect local area to start below ESP, e.g. at ESP - 4, and ESP + 4 would contains function arguments. It look like prolog/epilog generator (PEI::calculateFrameObjectOffsets) assumes local area offset is offset in the stack growth direction. For example, if there are 2 4-byte object, it will start with "Offset" of 4 and then go to "Offset" of 8... the actuall offsets set to stack objects will be -Offset -- in this case -4 and -8. So, it really l...

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 that properly? thank you, roman

Hello, it seems the Prolog/Epilog insertion does not correctly align stack for me. Consider the PEI::calculateFrameObjectOffsets method. It only aligns the stack if FFI->hasCalls() is true. The only place where MachineFrameInfo::setHasCalls is invoked is PEI::saveCallerSavedRegisters and the value 'true' is only passed when there are instructions with opcodes equal to either RegInfo->getCal...

...---------- Local vars ----------------- The problem is that the the first local variable is being assigned to the same location as the link register. I tried to use the OffsetOfLocalArea option, but do to alignment restrictions this increased the stack size. The offset of the local vars is set in calculateFrameObjectOffsets, so I added the following hack to eliminateFrameIndex: if (Offset < 0) //local variable Offset -= 4; Is there a better way? Thanks, Rafael

...particular, on entry to a function, before the prolog, the stack pointer (on X86) is aligned to an 8 byte boundary, but is actually 4 bytes from that alignment. Put another way, immediately before the call, the stack pointer was aligned to 8 bytes. > It look like prolog/epilog generator (PEI::calculateFrameObjectOffsets) > assumes local area offset is offset in the stack growth direction. For > example, if there are 2 4-byte object, it will start with "Offset" of 4 and > then go to "Offset" of 8... the actuall offsets set to stack objects will be > -Offset -- in this case -4 and -8...

...); } What's the division by 8 for? Neither 'CreateStackObject' nor 'getSpillAlignment' documentation say what units the size is, but everywhere it's in bytes. In my specific case, 'getSplillAlignment' returns 4, which becomes 0 after division. Later on, PEI::calculateFrameObjectOffsets gets this zero alignment and crashes with division by zero. I don't this zero alignment is reasonable at all. And ideas? Thanks, Volodya

...------ > > The problem is that the the first local variable is being assigned to > the same location as the link register. I tried to use the > OffsetOfLocalArea option, but do to alignment restrictions this > increased the stack size. > > The offset of the local vars is set in calculateFrameObjectOffsets, so > I added the following hack to eliminateFrameIndex: > > if (Offset < 0) //local variable > Offset -= 4; > > Is there a better way? I'm not sure I follow the question. It sounds like you should use the standard model, where local vars are allocated using variabl...

...RegScavenger for more than one registers: instead of state > for one register (ScavangedReg, ScavengedRC, ScavengedRestore) we need > need an array of such states that are handled correctly > * PEI::scavengeFrameVirtualRegs must be adopted to handle more than one > register > * PEI::calculateFrameObjectOffsets needs to handle the reserved scavenger > spill slot frame indexes I am not sure extending the scavenger is the right way to go about this. There are two different situations where we might need extra registers to spill something: 1. When spilling a weird register class like predicate registe...