search for: dw_op_regn

...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 for LLVM’s dbg.value. We could hypothetically >> repurpose DW_OP_stack_value to indicate that the SSA value passed to >> llvm.dbg.value *is* the variable’s value, and if the expression lacks >> DW_OP_stack_value, it must be a the address of the value. However, that is &...

...sions work. When a debugger begins evaluating a DWARF expression, it assumes that the resulting value will be a pointer to the variable in memory. For a debugger, this makes sense, because debug builds put things in memory and even after optimization many variables must be spilled. Only the special DW_OP_regN and DW_OP_stack_value expression opcodes change the location of the value from memory to register or stack value. 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 for LLVM’s db...

...sions work. When a debugger begins evaluating a DWARF expression, it assumes that the resulting value will be a pointer to the variable in memory. For a debugger, this makes sense, because debug builds put things in memory and even after optimization many variables must be spilled. Only the special DW_OP_regN and DW_OP_stack_value expression opcodes change the location of the value from memory to register or stack value. 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 for LLVM’s db...

...gt; >> 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 find this useful: >>> >>> So since we don't have DW_OP_regN for LLVM registers, we could sort of >>> assume the implicit first value on the stack is a pseudo-OP_regN of the >>> LLVM SSA register. >>> >> >> Yep, that's how we use DIExpressions in both IR and MIR: The LHS of the >> dbg.value and DBG_VALUE instr...

...t consistent. In LLVM IR today, the SSA value of the dbg.value *is* the interesting >>>> value, it is not the address, and we typically use empty DIExpressions. If >>>> the value is ultimately register allocated and the DIExpression is empty, >>>> we will emit a DW_OP_regN location expression. If the value is spilled, we >>>> usually don't need to append DW_OP_stack_value because the location is now >>>> a memory location, which can be described by DW_OP_[f]breg. >>>> >>>> Today, passes that want to add "plus 3...

...sions work. When a debugger begins evaluating a DWARF expression, it assumes that the resulting value will be a pointer to the variable in memory. For a debugger, this makes sense, because debug builds put things in memory and even after optimization many variables must be spilled. Only the special DW_OP_regN and DW_OP_stack_value expression opcodes change the location of the value from memory to register or stack value. 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 for LLVM’s db...