similar to: Ideas for managing DBG_VALUE machine instructions.

> On May 7, 2018, at 11:29 PM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.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

Hi, 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 on https://reviews.llvm.org/D45878, and since this is something that should be handled by all different

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

Awesome to read how it's coming along - I'm mostly aside from the debug location work, but had just one or two clarifying questions On Fri, Nov 6, 2020 at 10:27 AM Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > > Hi debug-info folks, > > Time for another update on the variable location "instruction referencing" > implementation I've been doing,

Hi debuginfo cabal, tl;dr: I'd like to know what people think about an alternative to DBG_VALUE instructions describing variable locations in registers, virtual or real. Before instruction selection in LLVM-IR we identify the _values_ of variables [0] by the instruction that computes the value; I believe we should be able to do the same post-isel, and it would avoid having to analyse register

Hi debug-info folks, Time for another update on the variable location "instruction referencing" implementation I've been doing, see this RFC [0, 1] for background. It's now at the point where I'd call it "done" (as far as software ever is), and so it's a good time to look at what results it produces. And here are the scores-on-the-doors using llvm-locstats, on

Hi Vedant, thanks for the detailed response, On Tue, Feb 25, 2020 at 7:23 AM Vedant Kumar <vedant_kumar at apple.com> wrote: > > Finally, being forced to always specify both the machine location and > > the program location at the same time (in a single DBG_VALUE) > > introduces un-necessary burdens. In MachineSink, when we sink between > > blocks an instruction that

> I don't see how this is a meaningful distinction in LLVM IR. In LLVM IR we only have SSA values. An SSA value could be an alloca, or a gep into an alloca, or spilled onto the stack at the MIR level, in which case the dbg.value should get lowered into a memory location (if it isn't explicitly a DW_OP_stack_value). I think the distinction is still important; even at the IR level, if we

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

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

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

Hi Quentin, Jonas looked further into the problem below, and asked me to submit his patch. Note the we have our own out-of-tree target, and we have not been able to reproduce this problem on an in-tree target. /Patrik Hägglund [MachineSinking] Conservatively clear kill flags after coalescing. This solves the problem of having a kill flag inside a loop with a definition of the register prior to

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. > **************************

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

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

+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

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

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,

> I can see how that could potentially be useful. I'm not sure how often we could practically make use of a situation like this, but I understand your motivation. Indeed, I don't expect us to cancel out DWARF expressions like that very often. Although that edge case is likely to be very rare, the _direct operator itself will appear very frequently, as it would be used for every