[PATCH] D67492: [DebugInfo] Add a DW_OP_LLVM_entry_value operation

[Adrian Prantl via Phabricator via llvm-commits]

aprantl added a comment.

Having suggested this, I think this is a good idea ;-)



================
Comment at: llvm/docs/LangRef.rst:4785
 - ``DW_OP_stack_value`` marks a constant value.
-- If an expression is marked with ``DW_OP_entry_value`` all register and
+- If an expression is marked with ``DW_OP_LLVM_entry_value`` all register and
   memory read operations refer to the respective value at the function entry.
----------------
It's ambiguous where in the expression DW_OP_LLVM_entry_value can appear. Perhaps add an example or improve the wording? I assume it is still legal to combine a DW_OP_LLVM_entry_value with other operations?


================
Comment at: llvm/docs/LangRef.rst:4788
+  The first operand of ``DW_OP_LLVM_entry_value`` is the size of following
   DWARF expression.
+  ``DW_OP_LLVM_entry_value`` may appear after the ``LiveDebugValues`` pass.
----------------
not "DWARF expression" but in terms of std::distance of DIExpression operation iterators, right?


================
Comment at: llvm/docs/LangRef.rst:4789
   DWARF expression.
-  ``DW_OP_entry_value`` may appear after the ``LiveDebugValues`` pass.
+  ``DW_OP_LLVM_entry_value`` may appear after the ``LiveDebugValues`` pass.
   LLVM only supports entry values for function parameters
----------------
may appear -> is introduced by


================
Comment at: llvm/docs/LangRef.rst:4793
   simple register location descriptions.
-  ``DW_OP_entry_value`` may also appear after the ``AsmPrinter`` pass when
+  ``DW_OP_LLVM_entry_value`` may also appear after the ``AsmPrinter`` pass when
   a call site parameter value (``DW_AT_call_site_parameter_value``)
----------------
is also introduced by


================
Comment at: llvm/lib/IR/DebugInfoMetadata.cpp:896
       // of following expression should be 1, because we support only
       // entry values of a simple register location.
       return I->get() == expr_op_begin()->get() && I->getArg(0) == 1 &&
----------------
Can someone remind me what the reason for this limitation was again? Do we still need it after this patch?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67492/new/

https://reviews.llvm.org/D67492