[llvm-dev] Concatenating DWARF location expressions

Adrian Prantl via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 24 08:48:31 PST 2019



> On Jan 24, 2019, at 6:04 AM, Markus Lavin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hello,
> 
> Could someone explain to me what the rules are for concatenation of DWARF location expressions?
> 
> For example in lib/CodeGen/PrologEpilogInserter.cpp there is a call to DIExpression::prepend to concatenate the stack slot address of a variable to an existing expression. Now the problem here is that the former is a 'Memory location description' while the latter could very well be a 'Implicit location description' (e.g. the sign extension from  lib/Transforms/Utils/Local.cpp) in which case a DW_OP_deref of some sort would be needed in between.
> 
> To me it seems that there is no clear way of knowing what to do when concatenating because there is no clear way of knowing the kind of the existing expression (is it Memory, Register or Implicit). 
> 
> Without having thought too much about it it would seem that having additional meta ops in the expression for the sole purpose of identifying what kind it is would be helpful when concatenating.
> 
> I could find similar topics being raised on the list in the past but was not able to find any clear conclusion.

Back when I added the prepend functionality I did so under the assumption that since the expressions are a stack-based postfix-notated language we can always prepend new operands without having to pay attention to what comes later in the expression. Back then LLVM didn't yet know about DW_OP_stack_value.

We don't distinguish DWARF location kinds in LLVM IR because it is not known where an LLVM SSA value will end up. Unfortunately we don't stick to that rule, since we do emit DW_OP_stack_values in various places, thus turning expressions definitely into implicit location descriptions. We still don't and can't distinguish between memory and register locations.

Since it sounds like the problem is only with implicit descriptions, would a rule such as "if the expression has a DW_OP_stack_value, add an extra DW_OP_deref" work for the PrologueEpilgueInserter or do we need something more principled?

-- adrian


More information about the llvm-dev mailing list