search for: framereg

...(DVInsn->getNumOperands() == 3) { if (DVInsn->getOperand(0).isReg()) { const MachineOperand RegOp = DVInsn->getOperand(0); const TargetRegisterInfo *TRI = Asm->TM.getRegisterInfo(); 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).getI...

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

...ooks 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 not think this is correct or am I missing something here ? For the sake of com...