[llvm-dev] [Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands

Tozer, Stephen via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 6 05:13:07 PDT 2020


> I can see how that could potentially be useful. I'm not sure how often we could practically make use of a situation like this, but I understand your motivation.

Indeed, I don't expect us to cancel out DWARF expressions like that very often. Although that edge case is likely to be very rare, the _direct operator itself will appear very frequently, as it would be used for every DBG_VALUE that represents a register location. This allows us to represent register locations in a way that doesn't rely on flags outside of the DIExpression, doesn't require changes to be made to the flag/DIExpression if the register is RAUWd by a constant or other value, and has a clear 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 say that any expression that isn't _direct, implicit, or empty 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/attachment-0001.html>


More information about the llvm-dev mailing list