[llvm-dev] Defining the DIExpression operator DW_OP_LLVM_arg

[Tozer, Stephen via llvm-dev]

> Is your intention to keep the implicit DW_OP_LLVM_arg 0 at the beginning of all DIExpressions referenced by debug intrinsics? From an ergonomics perspective it would bother me if the first argument of a 2-argument debug intrinsic is pushed implicitly and the second one isn't. However, transition dbg.value to a first-arg-is-explicit form is difficult, if we don't want to break LTO and bitcode compatibility. The cleanest way of doing this would be to create a dbg.value.version-2.0 intrinsic that uses the explicit form, and auto-upgrade the old dbg.value.

To clarify, the implicit DW_OP_LLVM_arg 0 is only for the non-variadic intrinsics, i.e. dbg.value and dbg.derefval. The version-2.0 intrinsic is more or less what I'm doing right now with dbg.value.list: a new version of dbg.value that uses explicit arguments and can have more than 1 of them. This means the intrinsic itself is used to distinguish between implicit and explicit, and it's my opinion that it may at some point be suitable to completely replace dbg.value. With that said, I haven't tried to do so in this stack of patches, as I suspect that trying to replace the intrinsic may result in a lengthy discussion that shouldn't need to block the introduction of the new intrinsic.

> Taking a step back, I think it is possible to separate the in-memory encoding from the visual representation. There is no reason why we couldn't encode DW_OP_LLVM_arg N in one 64-bit integer field. The DIExpression iterator can hide this detail. More generally, we could encode *all* fields in DIExpressions as, e.g, ULEB values in memory and hide that behind the iterator. With that perspective I think DW_OP_LLVM_arg N is the way to go, and if we are really bothered by the storage size, we can address this separately.

Agreed, I'm fine with either representation.