search for: llvm_direct

...Memory l-value Indirect $noreg, (deref), -> DW_OP_breg7 RSP+0 Memory l-value Indirect 0, (deref), -> DW_OP_breg7 RSP+0, DW_OP_deref Memory l-value Indirect The point of using DW_OP_LLVM_direct is that it supplants the current directness flag, without the redundancy or unintuitive behaviour that the flag does. I believe the only reason that the indirectness flag is necessary right now is to allow register locations to be emitted, by delineating the register location "$rsp, $noreg, ()...

...not affect the location type): 1. If the expression is empty, or any location arguments are $noreg => Empty 2. If the 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)...

...definition that doesn't clash with anything in the DWARF spec. Supporting the no-op DIExpression reduction is unlikely to have a huge impact in itself, but having a "stack_value that could be an l-value" nicely rounds out the LLVM representation for debug values. >If we had DW_OP_LLVM_direct: what would be the semantics of > >DIExpression(DW_OP_constu, 4, DW_OP_minus, DW_OP_LLVM_direct) > >versus > >DIExpression(DW_OP_constu, 4, DW_OP_minus) ? Once we have the _direct operator, which will be used for all register locations and some implicit locations, we can safely s...

> 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 to be an l-value if possible", DW_OP_stack_value means "this...

...quot; versus "this alloca is the variable's value", i.e. the variable itself is a pointer to a local variable. In IR, we implicitly distinguish between these by using dbg.declare/dbg.addr for the former, and dbg.value for the latter. In MIR, we use the indirectness flag instead. DW_OP_LLVM_direct can supplant the latter. Apologies for the somewhat confusing explanation thus far; in the IR stage, I think that actually we wouldn't need to produce DW_OP_LLVM_direct at all (although there's no harm in doing so) as long as we have the existing set of debug variable intrinsics, because &...

...nged my mind - I agree that we shouldn't use DW_OP_stack_value in this case, because it would be changing its meaning which is to explicitly declare the expression to be an implicit location/r-value. My current line of thinking is that it would be better to introduce a new operator, named DW_OP_LLVM_direct or something similar, which has the meaning "the variable's exact value is produced by the preceding expression", and would replace DW_OP_stack_value as it is currently used within LLVM. To summarise the logic behind using this operator: LLVM debug info does not need to explicitly ca...

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