search for: getframeindexreference

Hi, I'm gettign an assertion fail/crash in X86FrameLowering::GetFrameIndexReference when compiling the following bitcode: https://gist.github.com/carlokok/868cddebeb9acc8ccbac6253de0480b0 I tried removing the llvm.frameaddres calls but that's not it, where can I start looking for what my mistake here is? Code seems to verify just fine. ; #0 0x00e1afe8 llvm::X86FrameLower...

...uot;\01??_R0PAH at 8", i32 > 0, i32** %3] > > If I change either of them to have the %2 in both, it crashes llvm. > > > On 2016-10-17 18:02, Carlo Kok via llvm-dev wrote: > >> Hi, >> >> I'm gettign an assertion fail/crash in >> X86FrameLowering::GetFrameIndexReference when compiling the following >> bitcode: >> >> https://gist.github.com/carlokok/868cddebeb9acc8ccbac6253de0480b0 >> >> I tried removing the llvm.frameaddres calls but that's not it, where can >> I start looking for what my mistake here is? Code seems to verif...

...s to actually base + offset representation. However the assembly printer, while trying to emit debug info, sticks to the frame index representation and looks for a base+offset reference for -84 !! This is at DwarfCompileUnit.cpp:1334 ************************** int Offset = TFI->getFrameIndexReference(*Asm->MF, DVInsn->getOperand(1).getImm(), FrameReg); ************************** In my view we have lost information that (R30-84) is <fi#2>. The above statement is asking the Frame Lowering Information...

...inateFrameIndex 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::constructVariableDIE()? Is there something else I'm missing? Thanks, Richard -- Richard Osborne | XMOS http://www.xmos.com

Hi all, I am trying to implement statepoints for the AArch64 target and I’m running into the issue where the following bitcode: define i32 addrspace(1)* @test(i32 addrspace(1)* %ptr) gc "statepoint-example" { entry: call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 0, i32 0, i1 ()* @foo, i32 0, i32 0, i32 0, i32 0, i32 addrspace(1)* %ptr) ret

...tRegisterInfo(); if (DVInsn->getOperand(1).isImm() && TRI->getFrameRegister(*Asm->MF) == RegOp.getReg()) { unsigned FrameReg = 0; const TargetFrameLowering *TFI = Asm->TM.getFrameLowering(); int Offset = TFI->getFrameIndexReference(*Asm->MF, DVInsn->getOperand(1).getImm(), FrameReg); MachineLocation Location(FrameReg, Offset); addVariableAddress(DV, VariableDie, Location); If the intention is to handle the case where...

Hi, In the runtime system for GHC Haskell, the stack pointer register is not the same as the one defined by the operating system ABI, and it's difficult for GHC to change that. Following the example of CoreCLR in LLVM, it seems one way to remedy this situation is to define a new ABI (i.e., a new llvm::Triple::EnvironmentType ) and modify the code generator as-needed to respect to our ABI,

Thanks for the pointers! The problem was that the offset was mistakenly computed in the way it should be for Win64 exception handling. This is now fixed by taking the IgnoreSPUpdates argument into account in AArch64FrameLowering::getFrameIndexReferencePreferSP. Loïc > On 30 Jul 2019, at 20:21, Philip Reames <listmail at philipreames.com> wrote: > > Looking at PrologEpilogInserter and searching for STATEPOINT is a a good starting point. > > Philip > > On 7/27/19 2:22 AM, Sam Elliott via llvm-dev wrote: >> I th...

On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: > I'm investigating a bug associated with debug information that manifests > itself in the XCore backend (PR11105). I'd like to understand what the > expected behavior of eliminateFrameIndex() is when it is called on a > dbg_value machine instruction. That is up to the target. The TII::emitFrameIndexDebugValue() hook is

...a fixed and scalable part. For that we reason we created a new class StackOffset (https://reviews.llvm.org/D88982). AArch64 uses Stack-IDs to keep fixed- and scalable types apart, but AArch64FrameLowering finally allocates them together in the regular stack frame. StackOffset is returned by e.g. `getFrameIndexReference`, and is used in AArch64FrameLowering/AArch64RegisterInfo to calculate and resolve frame offsets. What works for scalable vectors today? ====================================== Today AArch64 SVE/SVE2 is probably the target with the most complete support, although recently Roger Ferrer also shared...

...tsize:32;encoding:uint;format:hex;gcc:60;dwarf:60". And I also set other "generic" attributes like sp, pc, ra, arg1~arg8 to related registers. I dig a little and find llvm dwarf generator uses TargetRegisterInfo::getFrameRegister() to obtain frame base, and uses TargetFrameLowering::getFrameIndexReference() to obtain frame base as well as frame offset of a variable. lldb is OK to check value of variable including both formal arguments and locals, although some line numbers are still improper. For example, in the case mentioned above, ".loc 1 2 0 prologue_end" is actually the start point o...

Thank you, Clayton. This is very helpful. We use the LLDB specific GDB remote extensions, and our debugger server supports "qRegisterInfo" package. "reg 0x3c" is the frame pointer. In the example mentioned above, we have SP = FP - 40 for current call frame. And variable "a" is stored at address (FP + -24) from asm instruction [FP + -24] = R3;; Thus we can conclude