search for: dvinsn

...is called. Implementing both TII::emitFrameIndexDebugValue() and AsmPrinter::getDebugValueLocation() in the XCore backend seems to fix the problem I was seeing. I'm still confused about what the following code in CompileUnit::constructVariableDIE is trying to do: if (const MachineInstr *DVInsn = DV->getMInsn()) { bool updated = false; if (DVInsn->getNumOperands() == 3) { if (DVInsn->getOperand(0).isReg()) { const MachineOperand RegOp = DVInsn->getOperand(0); const TargetRegisterInfo *TRI = Asm->TM.getRegisterInfo(); if (DVInsn-&g...

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

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. Currently the XCore target replaces the frame index with the frame register and sets the next operand to the byte offset from the frame

...le 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 to give it a base+offset pair for the frame index -84. I do...