similar to: [Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands

> I'm not sure this will work as stated here. Indirectness is (mostly) orthogonal to DW_OP_stack_value. DW_OP_stack_value denotes that we reconstructed the value of the variable, but it doesn't exist in the program ("The DW_OP_stack_value operation specifies that the object does not exist in memory but its value is nonetheless known"), for example, a constant value. I think we

> Can you elaborate what "direct" means? I'm having trouble understanding what the opposite (a non-exact value) would be. Apologies, "exact" was a misleading/incorrect term. By direct, I mean that the expression computes the value of the variable, as opposed to its memory address, or the value that it points to. Within LLVM, where we don't have DW_OP_reg/DW_OP_breg

> Yeah, because that decision can only be made much later in LLVM in AsmPrinter/DwarfExpression.cpp. > In DWARF, DW_OP_reg(x) is a register l-value, all others can either be l-values or r-values depending on whether there is a DW_OP_stack_value/DW_OP_implicit* at the end. Yes, it might not be clear but that's what I'm trying to say. Out of the non-empty DWARF locations, register and

> 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

> 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 Wed, Jul 8, 2020 at 9:29 AM Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > > On Jul 8, 2020, at 5:21 AM, Tozer, Stephen <stephen.tozer at sony.com> wrote: > > > >> To summarize my understanding: Neither of these operators is strictly necessary, since the same effect can be achieved by implicitly pushing all operands of a

On Wed, Jul 8, 2020 at 9:48 AM Adrian Prantl <aprantl at apple.com> wrote: > > > > > On Jul 8, 2020, at 9:33 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Jul 8, 2020 at 9:29 AM Adrian Prantl via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> > >> > >> > >>> On Jul 8, 2020, at 5:21

What would it look like without this extension? If we modeled it as if all the register values were already on the stack (an extension of the current way where the singular value is modeled as being already on the stack, if I understand it correctly?)? If it's decided that the best approach is to introduce something like DW_OP_LLVM_register - might be worth migrating to that first (basically

> That sounds to me to be the same concept that I am calling r-value vs. l-value. Do you agree, or is there some subtlety that I am missing? I've been assuming that the l-value vs r-value distinction is analogous to C++: an l-value can be written to by the debugger, an r-value cannot. A memory location and a register location are both l-values, while implicit locations (stack

> That makes sense, and I think for "direct" values in your definition it is true that all direct values are r-values. > Why do we need DW_OP_LLVM_direct when we already have DW_OP_LLVM_stack_value? Can you give an example of something that is definitely not a stack value, but direct? The difference in definition is the intention: DW_OP_LLVM_direct means "we'd like this

>As the person who has advocated for DW_OP_LLVM_arg(N) before, my main motivation was to resolve the ambiguity of constant DIExpressions: As a worst-case example: > >dbg.value(%undef, !DILocalVariable(x), DIExpression(DW_OP_constu, 42)) > >Is this undefined, or constant 42? > >But if we make dbg.value fully variadic with all parameters pushed to the stack ahead of time, we can

On Wed, Sep 6, 2017 at 10:01 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Sep 5, 2017 at 1:00 PM Reid Kleckner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> LLVM SSA values obviously do not have an address that we can take and >> they don’t live in registers, so neither the default memory location model >> nor DW_OP_regN make sense

> To summarize my understanding: Neither of these operators is strictly necessary, since the same effect can be achieved by implicitly pushing all operands of a DBG_VALUE to the stack, followed by a combination of DW_OP_dup, DW_OP_pick, DW_OP_swap, DW_OP_rot, and DW_OP_over. However, the resulting expressions can get very long and unwieldy and it is easier to generate efficient DWARF from

On Wed, Sep 6, 2017 at 5:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Wed, Sep 6, 2017 at 2:01 PM Reid Kleckner <rnk at google.com> wrote: > >> On Wed, Sep 6, 2017 at 10:01 AM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> I guess you described this already, but talking it through for >>> myself/maybe others will

Currently, the debug intrinsic functions each have 3 arguments: an SSA value representing either the address or Value of a local variable, a DILocalVariable, and a complex expression. If the SSA value is an Instruction, and that Instruction is at some point deleted, we attempt to salvage the SSA value by recreating the instruction within the complex expression. If the instruction cannot be

> On Nov 18, 2019, at 8:33 AM, Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > > Hi llvm-dev@, > > Switching focus to the LLVM implementation, the significant change is > using dbg.value's first operand to refer to a DILocalVariable, rather > than a Value. There's some impedance mismatch here, because all the > documentation (for example in the

Debug info today handles two cases reasonably well: 1. At -O0, dbg.declare does a good job describing variables that live at some known stack offset 2. With optimizations, variables promoted to SSA can be described with dbg.value This leaves behind a large hole in our optimized debug info: variables that cannot be promoted, typically because they are address-taken. This is

Hi Xiang, On Wed, Nov 11, 2020 at 1:59 AM Zhang, Xiang1 <xiang1.zhang at intel.com> wrote: > Jeremy wrote: > > ... The value %0 is live up to and including the ADD64ri but not past it, meaning LLVM today will drop the DBG_VALUE ... > > Just a little puzzle about the " drop the DBG_VALUE ", maybe I didn't get your key point, >

Currently, two patches undergoing review wish to add a new operator for LLVM's DIExpression: D70642[0], and D82363[1]. Though both of these cases use the same name, the operators have different meanings: in the former, it has the form `DW_OP_LLVM_argN` where N is in [0-7], and represents the Nth argument of the containing intrinsic; its purpose is to enable the intrinsic @llvm.dbg.derefval,

Hi Adrian & Stephen, One thought here: But — not all memory locations are l-values. If we have a DWARF location list for variable "x" which points to a memory address for the first n instructions and the switches to a constant for the remainder of the scope, the memory address is not guaranteed to be an l-value, because writing the the memory address cannot affect the later part of