search for: implicit_ptr

...pty will be a memory location. So for the first expression we would check to see if it could be emitted as a register location, and when that fails we emit a stack value: DW_OP_breg7 RSP+0, DW_OP_constu 4, DW_OP_minus, DW_OP_stack_value Since the second expression is not LLVM_direct, stack_value, implicit_ptr, or any other explicitly declared location type, then it must be a memory location, so we emit: DW_OP_breg7 RSP+0, DW_OP_constu 4, DW_OP_minus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201006/e4389654/...

...'s no harm in doing so) as long as we have the existing set of debug variable intrinsics, because "directness" is already made explicit by the choice of intrinsic. Every dbg.value would implicitly be LLVM_direct unless it has another implicit location specifier (such as stack_value or implicit_ptr). This would mean that we could have a debug value: dbg.value(%a, "a", (DW_OP_plus_uconst, 5)), with no stack_value necessary, as opposed to the current case where every dbg.value with a complex expression has stack_value (I believe). As discussed, one of the key distinctions that DW_OP_...

> 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