similar to: [LLVMdev] processFunctionBeforeFrameFinalized setting object offset without effect, stack frame layout wrong

Hi! I am trying to implement va_arg() on ppc32. Everything went smooth, except implementing va_arg() of 64bit int. Since i64 is not a legal type on ppc32 DAGTypeLegalizer::ExpandRes_VAARG() splits the va_arg(i64) into two i32 va_args. The problem with ppc32 va_arg is that it needs special "alignment" of its gpr pointer when the argument is i64. Ie. I need to know if I am lowering

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

Hi, Nicolas > Could you point me where those hooks are in the llvm code? I didn't find > any. Look into PrologEpilogInserter.cpp::PEI::runOnMachineFunction(). There are calls to hooks inside TargetRegisterInfo: TargetRegisterInfo::processFunctionBeforeCalleeSavedScan() and TargetRegisterInfo::processFunctionBeforeFrameFinalized(). Maybe they are not so convenient when working via JIT

> That is irrelevant. The PEI code needs to know how much stack space is > required for each call to allocate and align the stack frame properly. It > gets this info from the ADJCALLSTACK instructions. I see. Looking at PEI::calculateCalleeSavedRegisters shows that the ADJCALLSTACK instructions is used to set up MaxCallFrameSize. Adding debug prints also show that in the example code

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 (StackGrowsDown) everywhere, so that the current logic should not be

The X86 backend has this code: X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) : .... FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), That is, it uses "4" as local area offset. 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

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

I am having some problems defining the stack layout on ARM. It should look like Incoming vars ----------------- Saved Link Register ----------------- 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.

On Wed, 9 Jun 2004, Vladimir Prus wrote: > > The X86 backend has this code: > > X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) > : .... > FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), > > That is, it uses "4" as local area offset. Based on prior discussion this > should mean that the local

## Problem description One of the responsibilities of a target's implementation of TargetFrameLowering::emitPrologue is to set the frame pointer (if needed). Typically, the frame pointer will be stored to the stack just like the other callee-saved registers, and emitPrologue must insert the instruction to change its value after it was stored to the stack. Mips does this by looking at the

Hi Anton, Anton Korobeynikov wrote: > I don't see any huge problems with writing such pass: just create > stack frame objects at fixed offsets inside your MF pass - and you'll > done. The only problem is that you need to do this early - before > prologue / epilogue inserter code runs, since afterwards stack frame > layout is almostly finalized (at "high level")

Hi llvmdev, I'm trying to figure how llvm remembers stack slots allotted to callee saved registers on x86. In particular, llvm pushes registers in decreasing order of FrameIdxs [1], so the offsets they get (as returned by MFI->getObjectOffset) don't directly correspond to their actual stack locations. In X86FrameLowering's emitCalleeSavedFrameMoves, when emitting DWARF

I have a question about register scavenger. I am considering using register scavenger for MIPS to free up register AT which is currently reserved to load large immediates. All targets which currently use register scavenger to search for a scratch register (ARM, CellSPU, PowerPC and XCore) override function processFunctionBeforeCalleeSavedScan and call RegisterScavenger::setScavengingFrameIndex

hi! To continue the inflow of good news this week, let me announce that clang -integrated-as (ie. ELF part of MC) compiles all of FreeBSD! This includes things like booting kernel, gnu libstdc++, clang/LLVM itself and many other components that make up FreeBSD operating system. I personally consider this a milestone where -integrated-as should become the default for ELF/{x86_64,i386}. Many

I'm working on Position-independent code for 32-bit PowerPC, but running into a problem. At the beginning of each function, there's a pre-word that's the difference between the PICBase (.L1$pb) and the GOT. This works fine when generating assembly output, but it fails when generating ELF output, with the error "Cannot represent a difference across sections" (line 847,

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

Hi, My New Year's resolution is to complain (constructively) whenever I get a spurious build failure email from a buildbot. For new or infrequent contributors especially, they can be extremely confusing and unnecessarily alarming. This one below is the first build ever attempted by the builder, so how on earth can it have come up with a meaningful blame list? And in any case, surely we

Tim, How about the below option ? 1. Specify an existing generic armv7 CPU or the CPU which is close my custom variant. My custom variant can be treated as "cortex-a9" + hwdiv. So my CPU here is "cortex-a9" 2. Specify the ".arch_extension idiv" which is available as an extension for my custom variant. 3. Teach LLVM & Clang about your CPU's

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

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