Changes to the Debug Info
---------------------------------
-* The DWARFv5 feature of attaching `DW_AT_default_value` to defaulted template
+* The DWARFv5 feature of attaching ``DW_AT_default_value`` to defaulted template
parameters will now be available in any non-strict DWARF mode and in a wider
- range of cases than previously. (`D139953 <https://reviews.llvm.org/D139953>`_, `D139988 <https://reviews.llvm.org/D139988>`_)
+ range of cases than previously.
+ (`D139953 <https://reviews.llvm.org/D139953>`_,
+ `D139988 <https://reviews.llvm.org/D139988>`_)
-* The `DW_AT_name` on `DW_AT_typedef`s for alias templates will now omit defaulted
- template parameters. (`D142268 <https://reviews.llvm.org/D142268>`_)
+* The ``DW_AT_name`` on ``DW_AT_typedef``\ s for alias templates will now omit
+ defaulted template parameters. (`D142268 <https://reviews.llvm.org/D142268>`_)
+
+* The experimental ``@llvm.dbg.addr`` intrinsic has been removed (`D144801
+ <https://reviews.llvm.org/D144801>`_). IR inputs with this intrinsic are
+ auto-upgraded to ``@llvm.dbg.value`` with ``DW_OP_deref`` appended to the
+ ``DIExpression`` (`D144793 <https://reviews.llvm.org/D144793>`_).
Changes to the LLVM tools
---------------------------------
LLVM uses several intrinsic functions (name prefixed with "``llvm.dbg``") to
track source local variables through optimization and code generation.
-``llvm.dbg.addr``
+``llvm.dbg.declare``
^^^^^^^^^^^^^^^^^^^^
.. code-block:: llvm
- void @llvm.dbg.addr(metadata, metadata, metadata)
+ void @llvm.dbg.declare(metadata, metadata, metadata)
This intrinsic provides information about a local element (e.g., variable).
The first argument is metadata holding the address of variable, typically a
static alloca in the function entry block. The second argument is a
`local variable <LangRef.html#dilocalvariable>`_ containing a description of
the variable. The third argument is a `complex expression
-<LangRef.html#diexpression>`_. An `llvm.dbg.addr` intrinsic describes the
+<LangRef.html#diexpression>`_. An `llvm.dbg.declare` intrinsic describes the
*address* of a source variable.
.. code-block:: text
%i.addr = alloca i32, align 4
- call void @llvm.dbg.addr(metadata i32* %i.addr, metadata !1,
- metadata !DIExpression()), !dbg !2
+ call void @llvm.dbg.declare(metadata i32* %i.addr, metadata !1,
+ metadata !DIExpression()), !dbg !2
!1 = !DILocalVariable(name: "i", ...) ; int i
!2 = !DILocation(...)
...
%buffer = alloca [256 x i8], align 8
; The address of i is buffer+64.
- call void @llvm.dbg.addr(metadata [256 x i8]* %buffer, metadata !3,
- metadata !DIExpression(DW_OP_plus, 64)), !dbg !4
+ call void @llvm.dbg.declare(metadata [256 x i8]* %buffer, metadata !3,
+ metadata !DIExpression(DW_OP_plus, 64)), !dbg !4
!3 = !DILocalVariable(name: "i", ...) ; int i
!4 = !DILocation(...)
-A frontend should generate exactly one call to ``llvm.dbg.addr`` at the point
+A frontend should generate exactly one call to ``llvm.dbg.declare`` at the point
of declaration of a source variable. Optimization passes that fully promote the
-variable from memory to SSA values will replace this call with possibly
-multiple calls to `llvm.dbg.value`. Passes that delete stores are effectively
-partial promotion, and they will insert a mix of calls to ``llvm.dbg.value``
-and ``llvm.dbg.addr`` to track the source variable value when it is available.
-After optimization, there may be multiple calls to ``llvm.dbg.addr`` describing
-the program points where the variables lives in memory. All calls for the same
-concrete source variable must agree on the memory location.
-
-
-``llvm.dbg.declare``
-^^^^^^^^^^^^^^^^^^^^
-
-.. code-block:: llvm
-
- void @llvm.dbg.declare(metadata, metadata, metadata)
-
-This intrinsic is identical to `llvm.dbg.addr`, except that there can only be
-one call to `llvm.dbg.declare` for a given concrete `local variable
-<LangRef.html#dilocalvariable>`_. It is not control-dependent, meaning that if
-a call to `llvm.dbg.declare` exists and has a valid location argument, that
-address is considered to be the true home of the variable across its entire
-lifetime. This makes it hard for optimizations to preserve accurate debug info
-in the presence of ``llvm.dbg.declare``, so we are transitioning away from it,
-and we plan to deprecate it in future LLVM releases.
+variable from memory to SSA values will replace this call with possibly multiple
+calls to `llvm.dbg.value`. Passes that delete stores are effectively partial
+promotion, and they will insert a mix of calls to ``llvm.dbg.value`` to track
+the source variable value when it is available. After optimization, there may be
+multiple calls to ``llvm.dbg.declare`` describing the program points where the
+variables lives in memory. All calls for the same concrete source variable must
+agree on the memory location.
``llvm.dbg.value``
8. X = Y;
9. }
-.. FIXME: Update the following example to use llvm.dbg.addr once that is the
- default in clang.
-
Compiled to LLVM, this function would be represented like this:
.. code-block:: text
the equivalent location is used.
After MIR locations are assigned to each variable, machine pseudo-instructions
-corresponding to each ``llvm.dbg.value`` and ``llvm.dbg.addr`` intrinsic are
-inserted. There are two forms of this type of instruction.
+corresponding to each ``llvm.dbg.value`` intrinsic are inserted. There are two
+forms of this type of instruction.
The first form, ``DBG_VALUE``, appears thus: