llvm dev - Jan 2019 - Concatenating DWARF location expressions

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.


Thanks!


-Markus


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190124/ee1d17c4/attachment.html>

> 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

> From: aprantl at apple.com <aprantl at apple.com>
> 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?
Right, that could very well be sufficient for this particular case so I will
experiment with that. In general though and for the future it seems that it
would be of benefit to have additional metadata in the expressions indicating if
they describe e.g. a memory address, a value or whatnot. This would perhaps
allow us to implement a simple debug expression verifier.

Thanks!
-Markus