search for: dw_op_llvm_memory

...39;s not start mixing them up, it will just make the discussion more confusing. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Blaikie via llvm-dev Sent: Wednesday, September 06, 2017 10:02 AM To: Reid Kleckner; llvm-dev Subject: Re: [llvm-dev] RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value On Tue, Sep 5, 2017 at 1:00 PM Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Debug info today handles two cases reasonably well: 1. At -O0, dbg.declare does a good job describing variable...

...is that while > every address must be a pointer value, not every pointer value is an > address. Is this correct? > Mainly just for readability. We're encoding one bit of information: is the result of DWARF expression on the LLVM value argument the variable's address or value? The DW_OP_LLVM_memory proposal encodes that bit as a special opcode in the expression. The dbg.addr proposal makes it more first class: it's part of the IR, the intrinsic, not some possibly semantically unimportant metadata. People seem to prefer that. -------------- next part -------------- An HTML attachment was s...

...e, it accepts that information as more reliable and discards all DBG_VALUE instructions associated with that variable. So, we need something we can mix. We need a way to say, the variable lives in memory *at this program point*, and it might live somewhere else later on. I propose that we introduce DW_OP_LLVM_memory for this purpose, and then we transition from dbg.declare to dbg.value+DW_OP_LLVM_memory. Initially I believed that DW_OP_deref was the way to say this with existing DWARF expression opcodes, but I implemented that in https://reviews.llvm.org/D37311 and learned more about how DWARF expressions wor...

...les instead of having dbg.value instructions, then maybe we don't need dbg.value either. Thanks, --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Reid Kleckner via llvm-dev Sent: Tuesday, September 05, 2017 1:00 PM To: llvm-dev Subject: [llvm-dev] RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value 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...

...They just use DW_OP_regN, which is >> implicitly a value location. >> 6. Teach all passes that spill virtual registers used by DBG_VALUE to >> remove DW_OP_stack_value from the DIExpression, or add DW_OP_deref as >> appropriate. >> >> This should be equivalent to DW_OP_LLVM_memory, and more inline with >> DWARF location expression semantics, but it has a large migration cost. >> >> --- >> >> I think part of the reason I wanted to move in the DW_OP_LLVM_memory >> direction is that I originally wanted to add a memory offset operand to it. &g...

...alue for DBG_VALUEs with physical register operands. They just use DW_OP_regN, which is implicitly a value location. 6. Teach all passes that spill virtual registers used by DBG_VALUE to remove DW_OP_stack_value from the DIExpression, or add DW_OP_deref as appropriate. This should be equivalent to DW_OP_LLVM_memory, and more inline with DWARF location expression semantics, but it has a large migration cost. --- I think part of the reason I wanted to move in the DW_OP_LLVM_memory direction is that I originally wanted to add a memory offset operand to it. Our actual use cases for complex DWARF expressions typ...

On Thu, Sep 7, 2017 at 11:11 AM, Robinson, Paul <paul.robinson at sony.com> wrote: > Different intrinsics sounds like a good solution to me. J > > > > So what happens with the case where a variable is registerized but later > we decide to spill it? Presumably we'd have a dbg.addr to point to the > spill slot. In past compilers I've used, spill slots were

...gt; implicitly a value location. >>>> 6. Teach all passes that spill virtual registers used by DBG_VALUE to >>>> remove DW_OP_stack_value from the DIExpression, or add DW_OP_deref as >>>> appropriate. >>>> >>>> This should be equivalent to DW_OP_LLVM_memory, and more inline with >>>> DWARF location expression semantics, but it has a large migration cost. >>>> >>>> --- >>>> >>>> I think part of the reason I wanted to move in the DW_OP_LLVM_memory >>>> direction is that I originally...

I chatted with Chandler in person and came up with what I think is a much simpler design than my previous design in the thread titled "RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value". The crux of the problem in that thread is that we need a representation, particularly in the middle-end, to describe a variables address, at a particular program point. The reason we can't just use dbg.declare (at least as specified today)...