search for: dw_op_llvm_arg

...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 DIExpressions that explicitly refer to arguments. DW_OP_LLVM_argN has the advantage of using less memory, at the cost of limiting the number of arguments to a hardcoded value. I'd also add that since `DW_OP_pick N` picks the Nth argument from the top of the stack rather than the bottom, using it would require us to know how many elements are on the stack at...

...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 DIExpressions that explicitly refer to arguments. DW_OP_LLVM_argN has the advantage of using less memory, at the cost of limiting the number of arguments to a hardcoded value. > > > > I'd also add that since `DW_OP_pick N` picks the Nth argument from the top of the stack rather than the bottom, using it would require us to know how many elements...

...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 DIExpressions that explicitly refer to arguments. DW_OP_LLVM_argN has the advantage of using less memory, at the cost of limiting the number of arguments to a hardcoded value. > >>> > >>> I'd also add that since `DW_OP_pick N` picks the Nth argument from the top of the stack rather than the bottom, using it would require us to know ho...

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, which represents implicit pointers. In the latter, it has the form `DW_OP_LLVM_arg, N`, where N >= 0, and represents the Nth value in a variadic debug va...

...ntirely instead, and so I'm looking for any comments on this change before pushing ahead with it. There are a few differences between the MIR instructions: Old: DBG_VALUE %x, $noreg, !DILocalVariable("x"), !DIExpression() New: DBG_VALUE !DILocalVariable("x"), !DIExpression(DW_OP_LLVM_arg, 0, DW_OP_stack_value), %x 1) The "location" operand is moved to the end, as the instruction is now variadic such that every operand after the DIExpression is a location operand. 2) The second operand which currently represents "Indirectness" has been removed entirely, because...

...eference, at the end of compilation we would be able to salvage variable locations that had gone out of liveness. Imagine for a moment that we described the "index" variable as a variadic variable location, possibly looking like this: DBG_INSTR_REF {3, 0}, {2, 0}, !17, !DIExpression(DW_OP_LLVM_arg, 0, DW_OP_LLVM_arg, 1, DW_OP_plus) Where the {3, 0} instruction number referred to the 'baz' argument, and {2, 0} the value of 'i' on entry to the loop body. The workflow for salvaging would look something like this, after LiveDebugValues has finished doing dataflow things: 1) Ex...

..._OP_breg N`. We cannot specify these in LLVM since we only generate these operators at the end; previously, this was the job of the indirectness flag. Rather than reintroducing a flag just for this purpose however, I instead propose that we treat this as a special (albeit common) case: we can use `DW_OP_LLVM_arg 0, DW_OP_stack_value` with a single register operand. We already reduce the DIExpression to specialized DWARF operators at the point of DWARF emission, for example: `<Register N>, DW_OP_plus_uconst 5` becomes `DW_OP_bregN RSP+5`. If in any case where a stack value expression consists of only...

Hi Djordje, [Late reply as I was away, alas], For the example in https://reviews.llvm.org/D85012 , I'm not sure that just using an entry value is correct. The reason why the dbg.values for arguments are set to undef is not because the value can't be described, it's because deadargelim changes all the call sites to pass in 'undef', which I believe makes the value unrecoverable

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

...e expression ends with DW_OP_implicit_ptr => Implicit pointer (rvalue) 3. If the expression ends with DW_OP_stack_value =>Stack value (rvalue) // LLVM should produce LLVM_direct instead. 4. If the expression ends with DW_OP_LLVM_direct, then... 4a. If the preceding expression is just DW_OP_LLVM_arg, 0 and the only location operand is a register => Register location (lvalue) 4b. Otherwise => Stack value (rvalue) 5. Otherwise => Memory location (lvalue) This covers all the expected cases without ambiguity or almost any reduced expressiveness. I believe that the only expression t...

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

> 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