search for: dbg_values

Hi, I have a case that is causing me grief in the form of an assert. The prolog Epilog inserter tries to remove Frame Index references. I have a DBG_VALUE instruction that looks like this (alongwith the Frame Index). This is for the Hexagon backend. ************************** fi#2: size=4, align=4, at location [SP-84] DBG_VALUE <fi#2>, 0, !"fooBar"; line no:299

On Mar 7, 2012, at 5:19 PM, Pranav Bhandarkar <pranavb at codeaurora.org> wrote: > Hi, > > I have a case that is causing me grief in the form of an assert. The prolog > Epilog inserter tries to remove Frame Index references. I have a DBG_VALUE > instruction that looks like this (alongwith the Frame Index). This is for > the Hexagon backend. > **************************

Here is a proposal for improving DbgValueHistoryCalculator and the overall quality of debug locations. Focus: This is about lowering the DBG_VALUE machine instructions to DWARF location lists. Non-focus: This is not about (typical -O0) variables that permanently reside at a frame index and are described with dbg.declare intrinsics in the IR. These variables are stored in the MMI side-table and

I have a question regarding the DBG_VALUE instruction. IIUC the DBG_VALUE appears in two different forms: 1. DBG_VALUE( %Reg, %Reg, metadata) 2. DBG_VALUE(%Reg, offset, metadata) In the first version, the second operand is always a %noreg in the form of: DBG_VALUE(%Reg, %noreg, metadata). Is it possible to have a different version of DBG_VALUE that only has 2 operands which will have only

...nstructions introduced during SelectionDAG / PHI-elimination / other passes place the value into multiple vregs, that can have different liveness ranges. The problem: Those two differences between dbg.value intrinsics and DBG_VALUE instructions introduce some annoying artifacts that make handling DBG_VALUEs harder than dbg.values: * Identical DBG_VALUEs at different program locations can result in different variable values being presented (because their vreg operand might refer to a different def), * There can be multiple ways to represent a dbg.value in DBG_VALUEs (as you have a choice of vregs fro...

On 10/10/11 19:19, Jakob Stoklund Olesen wrote: > 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. >

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

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

Hi, The insertion of DBG_VALUE instructions for spills does not seem to be handling insert locations inside bundles well. If the spill instruction is part of a bundle, the new DBG_VALUE is inserted after it, but does not have the bundling flags set. This essentially means that if we start with a set of bundled instructions: MI1 [BundledSucc=true, BundledPred=false] MI2 [BundledSucc=false,

Hi again, Here is a small patch to fix this issue. Please note that since the problem results in broken bundles, it can result in invalid schedules for any VLIW back-ends using bundling to group instructions. Best regards Saurabh Verma From: Verma, Saurabh Sent: Tuesday, December 19, 2017 4:14 PM To: llvm-dev at lists.llvm.org Subject: DBG_VALUE insertion for spills breaks bundles Hi, The

Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely

...ins a value defined by the "somedef" instruction, b) The DBG_INSTR_REF needs a location for the value somedef defines. c) That value from "somedef" is copied to rbx, The new LiveDebugValues implementation doesn't have DBG_INSTR_REF yet, so I've written it to work with DBG_VALUEs too, to prove that it works just as well as the current implementation. It deals with code sequences such as: $rax = somedef DBG_VALUE $rax $rbx = COPY killed $rax ; Variable location is $rax, then moves to $rbx In which the same tracking has to occur, but the DBG_VALUE "read...

Hi, I work with an out-of-tree backend for a VLIW architecture and we use bundling extensively. We have opted to put DBG_VALUES inside bundles to keep them together with their originating instructions. However, as no (in-tree) backends do this to our knowledge, we have recently started to question if that's a wise approach. Several patches are needed to make bundled DBG_VALUEs work and since others don't do it, we...

Hi all, An early implementation of extending debug ranges and providing multiple location support is done here: http://reviews.llvm.org/D11933 Design document: https://docs.google.com/document/d/1noDVWTvTWBdYdweICPBwvwyt8QvX4KHl7j3XKNSg1nE/edit?usp=sharing On Jun 24, 2015, at 12:12 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: Hi Adrian, You might want to take a look at abandoned

Hi, (Resent with proper subject line) I recently found myself in trouble because the crash I had disappeared with -g, so I could not debug the program. This happened because the optimizer did not remember to consider DBG_VALUEs instruction so it changed its behavior, and the bug went hiding. I then started discussing this onhttps://reviews.llvm.org/D45878, and since this is something that should be handled by all different machine passes, the immediate question is now what utility functions should be made available for...

...m.org> wrote: > > Hi, (Resent with proper subject line) > > I recently found myself in trouble because the crash I had disappeared > with -g, so I could not debug the program. This happened because the > optimizer did not remember to consider DBG_VALUEs instruction so it > changed its behavior, and the bug went hiding. [Here are some (very high-level) thoughts.] As you suspect, that's clearly a bug. LLVM's ideal behavior is that the presence of debug informations shall not affect the contents of the .text section. As you also noticed,...

...t "drop the DBG_VALUE ") > 400B $eax = COPY %17:gr32, debug-location !51; phi.ll:23:1 > 416B RETQ implicit killed $eax, debug-location !51; phi.ll:23:1 > ____________________________________________________ Indeed; it's LiveDebugVariables that drops out-of-liveness DBG_VALUEs, as seen here: https://github.com/llvm/llvm-project/blob/68ac02c0dd2b8fda52ac132a86f72f2ad6b139a5/llvm/lib/CodeGen/LiveDebugVariables.cpp#L657 as the register allocator will not maintain the location of its vreg for positions that aren't live. -- Thanks, Jeremy

+llvmdev -llvm-commits Hi! I've got the following questions about DBG_VALUE instruction: 1) When I dump this instruction I see the line of the form: DBG_VALUE %EDI, 0, !"a"; line no:47 for two completely different cases: * when value of "a" is actually stored in a register %edi (this should be encoded as "DW_OP_reg5" in DWARF). * when value of

...by any instruction, and that there is no conflicting DBG_VALUE? -- adrian > > > On Wed, May 11, 2016 at 5:53 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > The most obvious place where it is lacking at the moment is that it only supports DBG_VALUEs in registers. Adding support for constant values, memory locations, and fp constants would be a big win! > > thanks, > Adrian > >> On May 11, 2016, at 2:52 PM, Francois Pichet <pichet2000 at gmail.com <mailto:pichet2000 at gmail.com>> wrote: >> >> In ret...

...)) > > and > > dbg.value(my_alloca, var, !DIExpression(DW_OP_deref)) ? So with that in mind, we wouldn't need to produce these, as in both cases the intent would be that the value of "var" is at the address given by "my_alloca". When we produce the corresponding DBG_VALUEs for these, both would end with DW_OP_LLVM_direct. This would change if we unified the IR debug intrinsics so that a single intrinsic could represent both memory locations and register/implicit locations, as opposed to the current state where the former can only be represented by dbg.declare/dbg.add...