[llvm-dev] Defining the DIExpression operator DW_OP_LLVM_arg
Tozer, Stephen via llvm-dev
llvm-dev at lists.llvm.org
Tue Jul 7 08:28:32 PDT 2020
Currently, two patches undergoing review wish to add a new operator for LLVM's DIExpression: D70642[0], and D82363[1]. Though both of these cases use the same name, the operators have different meanings: in the former, it has the form `DW_OP_LLVM_argN` where N is in [0-7], and represents the Nth argument of the containing intrinsic; its purpose is to enable the intrinsic @llvm.dbg.derefval, which represents implicit pointers. In the latter, it has the form `DW_OP_LLVM_arg, N`, where N >= 0, and represents the Nth value in a variadic debug value, which is being added in the same patch. Functionally these are quite similar; the main difference is that the latter picks the Nth value from a subset of the intrinsic's operands, while the former picks the Nth value from the entire containing intrinsic.
My personal opinion (possibly biased as the author of D82363) is that the best solution is to remove DW_OP_LLVM_argN from the implicit pointer work altogether. The operator introduced in that patch is more general-purpose than necessary; it is only used as DW_OP_LLVM_arg0 and in conjunction with @llvm.dbg.derefval, an intrinsic added in that patch. It seems at a glance that the functionality could be folded into the new intrinsic and operator pair by having them automatically refer to arg0. While it's possible that this general-purpose operator could have value in the future, I think that it is better to have specific operators for each use case, rather than an operator that could refer to a machine value, a local variable, or even the DIExpression that contains it. Also of note, the main feature that this operator would be useful for implementing is the feature that D82363 is adding: referencing multiple machine values in a debug value. The difference is that the version of the operator in the more recent patch is explicitly used to represent machine values; it cannot refer to anything else.
Finally, the implicit pointer patches haven't received an update in a while: the last comment or update was on January 10th. It is possible at this point that the work will not make it in for a very long time, and may be substantially changed when it does - I imagine there will be very little cost associated with using a different operator in that case.
I'm mainly looking to confirm that there are no objections to this, and also ensure that this change doesn't sneak past anyone if it is accepted.
[0] https://reviews.llvm.org/D70642
[1] https://reviews.llvm.org/D82363
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200707/563a97a3/attachment.html>
More information about the llvm-dev
mailing list