diff --git a/llvm/docs/AssignmentTracking.md b/llvm/docs/AssignmentTracking.md index ad9f790e75016..5a8bc5844eef6 100644 --- a/llvm/docs/AssignmentTracking.md +++ b/llvm/docs/AssignmentTracking.md @@ -226,10 +226,10 @@ to tackle: the storage address is not computed by an instruction (it's an argument value) and therefore we have nowhere to put the metadata attachment. To solve this we probably need another marker intrinsic to denote "the variable's - stack home is X address" - similar to `llvm.dbg.declare` and `llvm.dbg.addr` - except that it needs to compose with `llvm.dbg.assign` intrinsics such that - the stack home address is only selected as a location for the variable when - the `llvm.dbg.assign` intrinsics agree it should be. + stack home is X address" - similar to `llvm.dbg.declare` except that it needs + to compose with `llvm.dbg.assign` intrinsics such that the stack home address + is only selected as a location for the variable when the `llvm.dbg.assign` + intrinsics agree it should be. * Given the above (a special "the stack home is X" intrinsic), and the fact that we can only track assignments with fixed offsets and sizes, I think we diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index f420896bf2700..7f366d54a9fb4 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -6054,10 +6054,10 @@ sense that a debugger might modify its value), whereas *implicit locations* describe merely the actual *value* of a source variable which might not exist in registers or in memory (see ``DW_OP_stack_value``). -A ``llvm.dbg.addr`` or ``llvm.dbg.declare`` intrinsic describes an indirect -value (the address) of a source variable. The first operand of the intrinsic -must be an address of some kind. A DIExpression attached to the intrinsic -refines this address to produce a concrete location for the source variable. +A ``llvm.dbg.declare`` intrinsic describes an indirect value (the address) of a +source variable. The first operand of the intrinsic must be an address of some +kind. A DIExpression attached to the intrinsic refines this address to produce a +concrete location for the source variable. A ``llvm.dbg.value`` intrinsic describes the direct value of a source variable. The first operand of the intrinsic may be a direct or indirect value. A diff --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst index aed1df36b4901..718f57dba3ee2 100644 --- a/llvm/docs/ReleaseNotes.rst +++ b/llvm/docs/ReleaseNotes.rst @@ -163,12 +163,19 @@ Changes to the Metadata Info 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 `_, `D139988 `_) + range of cases than previously. + (`D139953 `_, + `D139988 `_) -* The `DW_AT_name` on `DW_AT_typedef`s for alias templates will now omit defaulted - template parameters. (`D142268 `_) +* The ``DW_AT_name`` on ``DW_AT_typedef``\ s for alias templates will now omit + defaulted template parameters. (`D142268 `_) + +* The experimental ``@llvm.dbg.addr`` intrinsic has been removed (`D144801 + `_). IR inputs with this intrinsic are + auto-upgraded to ``@llvm.dbg.value`` with ``DW_OP_deref`` appended to the + ``DIExpression`` (`D144793 `_). Changes to the LLVM tools --------------------------------- diff --git a/llvm/docs/SourceLevelDebugging.rst b/llvm/docs/SourceLevelDebugging.rst index 07468b1e75f17..be288f6f7f172 100644 --- a/llvm/docs/SourceLevelDebugging.rst +++ b/llvm/docs/SourceLevelDebugging.rst @@ -175,62 +175,45 @@ Debugger intrinsic functions 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 `_ containing a description of the variable. The third argument is a `complex expression -`_. An `llvm.dbg.addr` intrinsic describes the +`_. 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 -`_. 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`` @@ -312,9 +295,6 @@ following C fragment, for example: 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 @@ -609,8 +589,8 @@ in IR the location would be assigned ``undef`` by a debug intrinsic, and in MIR 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: