search for: getobjectoffset

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 information, this discrepancy gets fixed up by subtracting the offset reported by MFI->getObjectOffset from the minimum offset for any CSR (this is done by th...

...Das wrote: >> 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 information, this >> discrepancy gets fixed up by subtracting the offset reported by >> MFI->getObjectOffset from the minimum of...

...face to the OCaml garbage collector. When I try to compile the attached program using llc I get the following stack dump: 0 llc 0x00000000016611de 1 llc 0x00000000016616aa 2 libpthread.so.0 0x00007f90105fa270 3 llc 0x0000000000adb030 llvm::MachineFrameInfo::getObjectOffset(int) const + 32 4 llc 0x0000000000e73f1a llvm::X86FrameLowering::getFrameIndexOffset(llvm::MachineFunction const&, int) const + 74 5 llc 0x000000000119bed1 6 llc 0x000000000119bd1e 7 llc 0x00000000011e0dce llvm::MachineFunctionPass::runOnFunct...

...face to the OCaml garbage collector. When I try to compile the attached program using llc I get the following stack dump: 0 llc 0x00000000016611de 1 llc 0x00000000016616aa 2 libpthread.so.0 0x00007f90105fa270 3 llc 0x0000000000adb030 llvm::MachineFrameInfo::getObjectOffset(int) const + 32 4 llc 0x0000000000e73f1a llvm::X86FrameLowering::getFrameIndexOffset(llvm::MachineFunction const&, int) const + 74 5 llc 0x000000000119bed1 6 llc 0x000000000119bd1e 7 llc 0x00000000011e0dce llvm::MachineFunctionPass::runOnFunct...

The patch is in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061548.html . Okay to commit :) On Thu, Apr 24, 2008 at 7:35 PM, Arnold Schwaighofer <arnold.schwaighofer at gmail.com> wrote: > Another round :) > > I'll post the patch to llvm-commits cause i guess people might get > annoyed by my series of patches :). > > On Tue, Apr 22, 2008 at

Hello everybody, hi Evan, this patch changes the lowering of arguments for tail call optimized calls. Before arguments that could be overwritten by each other were explicitly lowered to a stack slot, not giving the register allocator a chance to optimize. Now a sequence of copyto/copyfrom virtual registers ensures that arguments are loaded in (virtual) registers before they are lowered to the

...nce at some of the other targets suggests this is the right thing to do (for example ARMBaseRegisterInfo::eliminateFrameIndex and Thumb1RegisterInfo::eliminateFrameIndex appear to handle dbg_value in exactly the same way). Unfortunately this results in an assertion firing in MachineFrameInfo::getObjectOffset(). This is due to CompileUnit::constructVariableDIE() passing the second operand of the dbg_value instruction (set to the byte offset) to getFrameIndexReference() which expects a frame index as an argument. Am I doing something wrong in eliminateFrameIndex()? Is this a bug in CompileUnit::cons...

Another round :) I'll post the patch to llvm-commits cause i guess people might get annoyed by my series of patches :). On Tue, Apr 22, 2008 at 10:34 PM, Evan Cheng <evan.cheng at apple.com> wrote: . >> +PPCTargetLowering::IsEligibleForTailCallOptimization(SDOperand Call, >> ... > That's fine. Please break it into two parts and move the target > independent part