[AMDGPU][NFC] DWARF extensions minor update

[t-tye]

Summary

1. Minor editorial corrections.
2. Allow different call frames to be associated with different target architectures in a single thread.

[scott.linder]

LGTM save one nit

llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst

2174

In most places we seem to parenthesize this kind of reference, do we want to do the same here? If not, should this be separated from the first bit by a comma or semicolon?

[t-tye]

• Correct DW_OP_LLVM_implicit_aspace_pointer to DW_OP_LLVM_aspace_implicit_pointer.

[t-tye]

Address review comment by adding a missing period.

[t-tye]

llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst

2174

There seems to be a mix of either a parenthesized and separate sentence. Added the missing period to this one.

llvm/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.md

6.  <i>A current target architecture</i>
     entities.
 
     <i>For example, target architecture specific entities include DWARF register
     identifiers, DWARF address space identifiers, the default address space, and
     the address space address sizes.</i>
 
     If specified:
 
-    - If the current thread is specified, then the current target architecture
-      must be the same as the target architecture of the current thread.
+    - If the current frame is specified, then the current target architecture
+      must be the same as the target architecture of the current frame.
+
+    - If the current frame is specified and is the top frame, and if the current
+      thread is specified, then the current target architecture must be the same
+      as the target architecture of the current thread.
+
     - If the current compilation unit is specified, then the current target
       architecture default address space address size must be the same as the
       `address_size` field in the header of the current compilation unit and any
       associated entry in the `.debug_aranges` section.
     - If the current program location is specified, then the current target
       architecture must be the same as the target architecture of any line
       number information entry (see [6.2 Line Number
       Information](#line-number-information)) corresponding to the current
7.  <i>A current object</i>
 
     It is required for the `DW_OP_push_object_address` operation.
 
     <i>For example, the `DW_AT_data_location` attribute on type debug
     information entries specifies the program object corresponding to a runtime
     descriptor as the current object when it evaluates its associated
     expression.</i>
 
-    The result is undefined if the location descriptor is invalid (see [3.5.3
+    The result is undefined if the location description is invalid (see [2.5.3
     DWARF Location Description](#dwarf-location-description)).
 
 8.  <i>An initial stack</i>
 
     This is a list of values or location descriptions that will be pushed on the
     operation expression evaluation stack in the order provided before
     evaluation of an operation expression starts.
 
     Some debugger information entries have attributes that evaluate their DWARF
     expression value with initial stack entries. In all other cases the initial
     stack is empty.
 
-    The result is undefined if any location descriptors are invalid (see [3.5.3
+    The result is undefined if any location descriptions are invalid (see [2.5.3
     DWARF Location Description](#dwarf-location-description)).
 
 If the evaluation requires a context element that is not specified, then the
 result of the evaluation is an error.
 
 <i>A DWARF expression for a location description may be able to be evaluated
 without a thread, call frame, program location, or architecture context. For
 example, the location of a global variable may be able to be evaluated without
4.  `DW_OP_bra`
 
     Otherwise, the DWARF expression is ill-formed if the updated operation
     position is not in the range of the first to last operation inclusive, or
     not at the start of an operation.
 
 5.  `DW_OP_call2, DW_OP_call4, DW_OP_call_ref`
 
     `DW_OP_call2`, `DW_OP_call4`, and `DW_OP_call_ref` perform DWARF procedure
-    calls during evaluation of a DWARF expression.
+    calls during evaluation of a DWARF operation expression.
 
     `DW_OP_call2` and `DW_OP_call4`, have one operand that is, respectively, a
     2-byte or 4-byte unsigned offset DR that represents the byte offset of a
     debugging information entry D relative to the beginning of the current
     compilation unit.
 
     `DW_OP_call_ref` has one operand that is a 4-byte unsigned value in the
     32-bit DWARF format, or an 8-byte unsigned value in the 64-bit DWARF format,
1.  `DW_OP_regval_type`
     > simply interpreted as a value of T. If a conversion is wanted it can be
     > done explicitly using a `DW_OP_convert` operation.
     >
     > GDB has a per register hook that allows a target specific conversion on a
     > register by register basis. It defaults to truncation of bigger registers.
     > Removing use of the target hook does not cause any test failures in common
     > architectures. If the compiler for a target architecture did want some
     > form of conversion, including a larger result type, it could always
-    > explicitly used the `DW_OP_convert` operation.
+    > explicitly use the `DW_OP_convert` operation.
     >
     > If T is a larger type than the register size, then the default GDB
     > register hook reads bytes from the next register (or reads out of bounds
     > for the last register!). Removing use of the target hook does not cause
     > any test failures in common architectures (except an illegal hand written
     > assembly test). If a target architecture requires this behavior, these
     > extensions allow a composite location description to be used to combine
     > multiple registers.
8.  `DW_OP_entry_value` <i>Deprecated</i>
 
     If the result of E is a location description L (see [2.5.4.4.4 Register
     Location Description
     Operations](#register-location-description-operations)), and the last
     operation executed by E is a `DW_OP_reg*` for register R with a target
     architecture specific base type of T, then the contents of the register are
     retrieved as if a `DW_OP_deref_type DR` operation was performed where DR is
     the offset of a hypothetical debug information entry in the current
-    compilation unit for T. The resulting value V s pushed on the stack.
+    compilation unit for T. The resulting value V is pushed on the stack.
 
     <i>Using `DW_OP_reg*` provides a more compact form for the case where the
     value was in a register on entry to the subprogram.</i>
 
     > NOTE: It is unclear how this provides a more compact expression, as
     > `DW_OP_regval_type` could be used which is marginally larger.
 
     If the result of E is a value V, then V is pushed on the stack.
3.  `DW_OP_form_tls_address`
     description that corresponds to the thread-local storage address TA.
 
     The meaning of the thread-local storage address TA is defined by the
     run-time environment. If the run-time environment supports multiple
     thread-local storage blocks for a single thread, then the block
     corresponding to the executable or shared library containing this DWARF
     expression is used.
 
-    <i>Some implementations of C, C++, Fortran, and other languages support a
+    <i>Some implementations of C, C++, Fortran, and other languages, support a
     thread-local storage class. Variables with this storage class have distinct
     values and addresses in distinct threads, much as automatic variables have
     distinct values and addresses in each subprogram invocation. Typically,
     there is a single block of storage containing all thread-local variables
     declared in the main executable, and a separate block for the variables
     declared in each shared library. Each thread-local variable can then be
     accessed in its block using an identifier. This identifier is typically a
     byte offset into the block and pushed onto the DWARF stack by one of the
2.  `DW_OP_stack_value`
     It pushes a location description L with one implicit location description SL
     on the stack. SL specifies LS with a bit offset of 0.
 
     <i>The `DW_OP_stack_value` operation specifies that the object does not
     exist in memory, but its value is nonetheless known. In this form, the
     location description specifies the actual value of the object, rather than
     specifying the memory or register storage that holds the value.</i>
 
-    See [2.5.4.4.5 Implicit Location Description
-    Operations](#implicit-location-description-operations) for special
-    rules concerning implicit pointer values produced by dereferencing implicit
-    location descriptions created by the `DW_OP_implicit_pointer` operation.
+    See `DW_OP_implicit_pointer` (following) for special rules concerning
+    implicit pointer values produced by dereferencing implicit location
+    descriptions created by the `DW_OP_implicit_pointer` operation.
 
     > NOTE: Since location descriptions are allowed on the stack, the
     > `DW_OP_stack_value` operation no longer terminates the DWARF operation
     > expression execution as in DWARF Version 5.
 
 3.  `DW_OP_implicit_pointer`
 
     <i>An optimizing compiler may eliminate a pointer, while still retaining the
3.  `DW_OP_implicit_pointer`
 
     `DW_OP_implicit_pointer` has two operands. The first operand is a 4-byte
     unsigned value in the 32-bit DWARF format, or an 8-byte unsigned value in
     the 64-bit DWARF format, that represents the byte offset DR of a debugging
     information entry D relative to the beginning of the `.debug_info` section
     that contains the current compilation unit. The second operand is a signed
     LEB128 integer that represents a byte displacement B.
 
-    <i>Note that D may not be in the current compilation unit.</i>
+    <i>Note that D might not be in the current compilation unit.</i>
 
     <i>The first operand interpretation is exactly like that for
     `DW_FORM_ref_addr`.</i>
 
     The address space identifier AS is defined as the one corresponding to the
     target architecture specific default address space.
 
     The address size S is defined as the address bit size of the target
3.  `DW_OP_implicit_pointer`
     an implicit location storage that is the same as LS, unless both the
     following conditions are met:
 
     1.  All retrieved bits come from an implicit location description that
         refers to an implicit location storage that is the same as LS.
 
         <i>Note that all bits do not have to come from the same implicit
         location description, as L' may involve composite location
-        descriptors.</i>
+        descriptions.</i>
 
     2.  The bits come from consecutive ascending offsets within their respective
         implicit location storage.
 
     <i>These rules are equivalent to retrieving the complete contents of LS.</i>
 
     If both the above conditions are met, then the value V pushed by the
     `DW_OP_deref*` operation is an implicit pointer value IPV with a target
2.  A `DW_TAG_subprogram` or `DW_TAG_entry_point` debugger information entry may
     have a `DW_AT_frame_base` attribute, whose value is a DWARF expression E.
 
     The result of the attribute is obtained by evaluating E with a context that
     has a result kind of a location description, an unspecified object, the
     compilation unit that contains E, an empty initial stack, and other context
     elements corresponding to the source language thread of execution upon which
     the user is focused, if any.
 
-    The DWARF is ill-formed if E contains an `DW_OP_fbreg` operation, or the
+    The DWARF is ill-formed if E contains a `DW_OP_fbreg` operation, or the
     resulting location description L is not comprised of one single location
     description SL.
 
     If SL is a register location description for register R, then L is replaced
     with the result of evaluating a `DW_OP_bregx R, 0` operation. This computes
     the frame base memory location description in the target architecture
     default address space.
 
1.  The `DW_TAG_ptr_to_member_type` debugging information entry has a
     elements corresponding to the source language thread of execution upon which the
     user is focused, if any. The first stack entry is the value of the pointer to
     member object itself. The second stack entry is the location description of the
     base of the entire class, structure, or union instance containing the member
     whose location is being calculated. The result of the evaluation is the location
     description of the member of the class to which the pointer to member entry
     points.
 
-### A.5.16 Dynamic Type Entries
+### A.5.18 Dynamic Properties of Types
+
+#### A.5.18.1 Data Location
 
 1.  The `DW_AT_data_location` attribute may be used with any type that provides one
     or more levels of hidden indirection and/or run-time parameters in its
     representation. Its value is a DWARF operation expression E which computes the
     location description of the data for an object. When this attribute is omitted,
     the location description of the data is the same as the location description of
     the object.
 

llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst

 generalizes DWARF to work with bit fields. This is generally not possible in
 DWARF Version 5.
 
 The ``DW_OP_*piece`` operations only allow literal indices. A way to use a
 computed offset of an arbitrary location description (such as a vector register)
 is required. The offset operations provide this ability since they can be used
 to compute a location description on the stack.
 
+It could be possible to define ``DW_OP_plus``, ``DW_OP_plus_uconst``, and
+``DW_OP_minus`` to operate on location descriptions to avoid needing
+``DW_OP_LLVM_offset`` and ``DW_OP_LLVM_offset_uconst``. However, this is not
+proposed since currently the arithmetic operations are defined to require values
+of the same base type and produces a result with the same base type. Allowing
+these operations to act on location descriptions would permit the first operand
+to be a location description and the second operand to be an integral value
+type, or vice versa, and return a location description. This complicates the
+rules for implicit conversions between default address space memory location
+descriptions and generic base type values. Currently the rules would convert
+such a location description to the memory address value and then perform two's
+compliment wrap around arithmetic. If the result was used as a location
+description, it would be implicitly converted back to a default address space
+memory location description. This is different to the overflow rules on location
+descriptions. To allow control, an operation that converts a memory location
+description to an address integral type value would be required. Keeping a
+separation of location description operations and arithmetic operations avoids
+this semantic complexity.
+
 See ``DW_OP_LLVM_offset``, ``DW_OP_LLVM_offset_uconst``, and
 ``DW_OP_LLVM_bit_offset`` in
 :ref:`amdgpu-dwarf-general-location-description-operations`.
 
 2.5 Generalize Creation of Undefined Location Descriptions
 ----------------------------------------------------------
 
 Current DWARF uses an empty expression to indicate an undefined location

 dword of the vector register. It also allows the compiler to produce DWARF
 that indexes the vector register if it spills scalar registers into portions
 of a vector register.
 
 Since DWARF stack value entries have a base type and AMDGPU registers are a
 vector of dwords, the ability to specify that a base type is a vector is
 required.
 
-See ``DW_AT_LLVM_vector_size`` in :ref:`amdgpu-dwarf-literal-operations`.
+See ``DW_AT_LLVM_vector_size`` in :ref:`amdgpu-dwarf-base-type-entries`.
 
 .. _amdgpu-dwarf-operation-to-create-vector-composite-location-descriptions:
 
 2.10 DWARF Operations to Create Vector Composite Location Descriptions
 ----------------------------------------------------------------------
 
 AMDGPU optimized code may spill vector registers to non-global address space
 memory, and this spilling may be done only for SIMT lanes that are active on
*A current target architecture*
   entities.
 
   *For example, target architecture specific entities include DWARF register
   identifiers, DWARF lane identifiers, DWARF address space identifiers, the
   default address space, and the address space address sizes.*
 
   If specified:
 
-  * If the current thread is specified, then the current target architecture
-    must be the same as the target architecture of the current thread.
+  * If the current frame is specified, then the current target architecture must
+    be the same as the target architecture of the current frame.
+
+  * If the current frame is specified and is the top frame, and if the current
+    thread is specified, then the current target architecture must be the same
+    as the target architecture of the current thread.
 
   * If the current compilation unit is specified, then the current target
     architecture default address space address size must be the same as the
     ``address_size`` field in the header of the current compilation unit and any
     associated entry in the ``.debug_aranges`` section.
 
   * If the current program location is specified, then the current target
     architecture must be the same as the target architecture of any line number
*A current object*
   The location description of a program object.
 
   It is required for the ``DW_OP_push_object_address`` operation.
 
   *For example, the* ``DW_AT_data_location`` *attribute on type debug
   information entries specifies the program object corresponding to a runtime
   descriptor as the current object when it evaluates its associated expression.*
 
-  The result is undefined if the location descriptor is invalid (see
+  The result is undefined if the location description is invalid (see
   :ref:`amdgpu-dwarf-location-description`).
 
 *An initial stack*
 
   This is a list of values or location descriptions that will be pushed on the
   operation expression evaluation stack in the order provided before evaluation
   of an operation expression starts.
 
   Some debugger information entries have attributes that evaluate their DWARF
   expression value with initial stack entries. In all other cases the initial
   stack is empty.
 
-  The result is undefined if any location descriptors are invalid (see
+  The result is undefined if any location descriptions are invalid (see
   :ref:`amdgpu-dwarf-location-description`).
 
 If the evaluation requires a context element that is not specified, then the
 result of the evaluation is an error.
 
 *A DWARF expression for a location description may be able to be evaluated
 without a thread, lane, call frame, program location, or architecture context.
 For example, the location of a global variable may be able to be evaluated
4.  ``DW_OP_bra``
 
     Otherwise, the DWARF expression is ill-formed if the updated operation
     position is not in the range of the first to last operation inclusive, or
     not at the start of an operation.
 
 5.  ``DW_OP_call2, DW_OP_call4, DW_OP_call_ref``
 
     ``DW_OP_call2``, ``DW_OP_call4``, and ``DW_OP_call_ref`` perform DWARF
-    procedure calls during evaluation of a DWARF expression.
+    procedure calls during evaluation of a DWARF operation expression.
 
     ``DW_OP_call2`` and ``DW_OP_call4``, have one operand that is, respectively,
     a 2-byte or 4-byte unsigned offset DR that represents the byte offset of a
     debugging information entry D relative to the beginning of the current
     compilation unit.
 
     ``DW_OP_call_ref`` has one operand that is a 4-byte unsigned value in the
     32-bit DWARF format, or an 8-byte unsigned value in the 64-bit DWARF format,
.. note::
       interpreted as a value of T. If a conversion is wanted it can be done
       explicitly using a ``DW_OP_convert`` operation.
 
       GDB has a per register hook that allows a target specific conversion on a
       register by register basis. It defaults to truncation of bigger registers.
       Removing use of the target hook does not cause any test failures in common
       architectures. If the compiler for a target architecture did want some
       form of conversion, including a larger result type, it could always
-      explicitly used the ``DW_OP_convert`` operation.
+      explicitly use the ``DW_OP_convert`` operation.
 
       If T is a larger type than the register size, then the default GDB
       register hook reads bytes from the next register (or reads out of bounds
       for the last register!). Removing use of the target hook does not cause
       any test failures in common architectures (except an illegal hand written
       assembly test). If a target architecture requires this behavior, these
       extensions allow a composite location description to be used to combine
       multiple registers.
.. note::
       reason to restrict it.
 
     It is an evaluation error if any bit of the value is retrieved from the
     undefined location storage or the offset of any bit exceeds the size of the
     location storage LS specified by any single location description SL of L.
 
     See :ref:`amdgpu-dwarf-implicit-location-description-operations` for special
     rules concerning implicit location descriptions created by the
-    ``DW_OP_implicit_pointer`` and ``DW_OP_LLVM_implicit_aspace_pointer``
+    ``DW_OP_implicit_pointer`` and ``DW_OP_LLVM_aspace_implicit_pointer``
     operations.
 
 5.  ``DW_OP_xderef`` *Deprecated*
 
     ``DW_OP_xderef`` pops two stack entries. The first must be an integral type
     value that represents an address A. The second must be an integral type
     value that represents a target architecture specific address space
     identifier AS.

 the memory location description.
 
 A location description that is comprised of one byte address memory location
 description SL is defined to be a memory byte address location description. It
 has a byte address equal to A and an address space equal to AS of the
 corresponding SL.
 
 ``DW_ASPACE_none`` is defined as the target architecture default address space.
+See :ref:`amdgpu-dwarf-segment_addresses``.
 
 If a stack entry is required to be a location description, but it is a value V
 with the generic type, then it is implicitly converted to a location description
 L with one memory location description SL. SL specifies the memory location
 storage that corresponds to the target architecture default address space with a
 bit offset equal to V scaled by 8 (the byte size).
 
 .. note::
3.  ``DW_OP_LLVM_form_aspace_address`` *New*
     with the current context of the access operation.*
 
     The DWARF expression is ill-formed if AS is not one of the values defined by
     the target architecture specific ``DW_ASPACE_*`` values.
 
     See :ref:`amdgpu-dwarf-implicit-location-description-operations` for special
     rules concerning implicit pointer values produced by dereferencing implicit
     location descriptions created by the ``DW_OP_implicit_pointer`` and
-    ``DW_OP_LLVM_implicit_aspace_pointer`` operations.
+    ``DW_OP_LLVM_aspace_implicit_pointer`` operations.
 
 4.  ``DW_OP_form_tls_address``
 
     ``DW_OP_form_tls_address`` pops one stack entry that must be an integral
     type value and treats it as a thread-local storage address TA.
 
     It pushes a location description L with one memory location description SL
     on the stack. SL is the target architecture specific memory location
     description that corresponds to the thread-local storage address TA.
 
     The meaning of the thread-local storage address TA is defined by the
     run-time environment. If the run-time environment supports multiple
     thread-local storage blocks for a single thread, then the block
     corresponding to the executable or shared library containing this DWARF
     expression is used.
 
-    *Some implementations of C, C++, Fortran, and other languages support a
+    *Some implementations of C, C++, Fortran, and other languages, support a
     thread-local storage class. Variables with this storage class have distinct
     values and addresses in distinct threads, much as automatic variables have
     distinct values and addresses in each subprogram invocation. Typically,
     there is a single block of storage containing all thread-local variables
     declared in the main executable, and a separate block for the variables
     declared in each shared library. Each thread-local variable can then be
     accessed in its block using an identifier. This identifier is typically a
     byte offset into the block and pushed onto the DWARF stack by one of the*
2.  ``DW_OP_stack_value``
     It pushes a location description L with one implicit location description SL
     on the stack. SL specifies LS with a bit offset of 0.
 
     *The* ``DW_OP_stack_value`` *operation specifies that the object does not
     exist in memory, but its value is nonetheless known. In this form, the
     location description specifies the actual value of the object, rather than
     specifying the memory or register storage that holds the value.*
 
-    See :ref:`amdgpu-dwarf-implicit-location-description-operations` for special
-    rules concerning implicit pointer values produced by dereferencing implicit
-    location descriptions created by the ``DW_OP_implicit_pointer`` and
-    ``DW_OP_LLVM_implicit_aspace_pointer`` operations.
+    See ``DW_OP_implicit_pointer`` (following) for special rules concerning
+    implicit pointer values produced by dereferencing implicit location
+    descriptions created by the ``DW_OP_implicit_pointer`` and
+    ``DW_OP_LLVM_aspace_implicit_pointer`` operations.
 
     .. note::
 
       Since location descriptions are allowed on the stack, the
       ``DW_OP_stack_value`` operation no longer terminates the DWARF operation
       expression execution as in DWARF Version 5.
 
 3.  ``DW_OP_implicit_pointer``
3.  ``DW_OP_implicit_pointer``
 
     ``DW_OP_implicit_pointer`` has two operands. The first operand is a 4-byte
     unsigned value in the 32-bit DWARF format, or an 8-byte unsigned value in
     the 64-bit DWARF format, that represents the byte offset DR of a debugging
     information entry D relative to the beginning of the ``.debug_info`` section
     that contains the current compilation unit. The second operand is a signed
     LEB128 integer that represents a byte displacement B.
 
-    *Note that D may not be in the current compilation unit.*
+    *Note that D might not be in the current compilation unit.*
 
     *The first operand interpretation is exactly like that for*
     ``DW_FORM_ref_addr``\ *.*
 
     The address space identifier AS is defined as the one corresponding to the
     target architecture specific default address space.
 
     The address size S is defined as the address bit size of the target
3.  ``DW_OP_implicit_pointer``
     description L', and retrieves S bits, such that any retrieved bits come from
     an implicit location storage that is the same as LS, unless both the
     following conditions are met:
 
     1.  All retrieved bits come from an implicit location description that
         refers to an implicit location storage that is the same as LS.
 
         *Note that all bits do not have to come from the same implicit location
-        description, as L' may involve composite location descriptors.*
+        description, as L' may involve composite location descriptions.*
 
     2.  The bits come from consecutive ascending offsets within their respective
         implicit location storage.
 
     *These rules are equivalent to retrieving the complete contents of LS.*
 
     If both the above conditions are met, then the value V pushed by the
     ``DW_OP_deref*`` operation is an implicit pointer value IPV with a target

 
 Although DWARF address space identifiers are target architecture specific,
 ``DW_ASPACE_none`` is a common address space supported by all target
 architectures.
 
 DWARF address space identifiers are used by:
 
 * The DWARF expression operations: ``DW_OP_LLVM_aspace_bregx``,
-  ``DW_OP_LLVM_form_aspace_address``, ``DW_OP_LLVM_implicit_aspace_pointer``,
+  ``DW_OP_LLVM_form_aspace_address``, ``DW_OP_LLVM_aspace_implicit_pointer``,
   and ``DW_OP_xderef*``.
 
 * The CFI instructions: ``DW_CFA_LLVM_def_aspace_cfa`` and
   ``DW_CFA_LLVM_def_aspace_cfa_sf``.
 
 .. note::
 
   With the definition of DWARF address classes and DWARF address spaces in these
2.  A ``DW_TAG_subprogram`` or ``DW_TAG_entry_point`` debugger information entry
     E.
 
     The result of the attribute is obtained by evaluating E with a context that
     has a result kind of a location description, an unspecified object, the
     compilation unit that contains E, an empty initial stack, and other context
     elements corresponding to the source language thread of execution upon which
     the user is focused, if any.
 
-    The DWARF is ill-formed if E contains an ``DW_OP_fbreg`` operation, or the
+    The DWARF is ill-formed if E contains a ``DW_OP_fbreg`` operation, or the
     resulting location description L is not comprised of one single location
     description SL.
 
     If SL is a register location description for register R, then L is replaced
     with the result of evaluating a ``DW_OP_bregx R, 0`` operation. This
     computes the frame base memory location description in the target
     architecture default address space.
 
3.  If a ``DW_TAG_subprogram`` or ``DW_TAG_entry_point`` debugger information
     compilation unit that contains E, an empty initial stack, and other context
     elements corresponding to the source language thread of execution upon which
     the user is focused, if any. The result of the evaluation is the location
     description L of the *canonical frame address* (see
     :ref:`amdgpu-dwarf-call-frame-information`) of the relevant call frame of
     the subprogram instance that immediately lexically encloses the current call
     frame's subprogram or entry point.
 
-    The DWARF is ill-formed if L is is not comprised of one memory location
+    The DWARF is ill-formed if L is not comprised of one memory location
     description for one of the target architecture specific address spaces.
 
     .. note::
 
       The following new attributes are added.
 
 4.  For languages that are implemented using a SIMT execution model, a
     ``DW_TAG_subprogram``, ``DW_TAG_inlined_subroutine``, or
1.  The ``DW_TAG_ptr_to_member_type`` debugging information entry has a
     and other context elements corresponding to the source language thread of
     execution upon which the user is focused, if any. The first stack entry is
     the value of the pointer to member object itself. The second stack entry is
     the location description of the base of the entire class, structure, or
     union instance containing the member whose location is being calculated. The
     result of the evaluation is the location description of the member of the
     class to which the pointer to member entry points.
 
-A.5.16 Dynamic Type Entries
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+A.5.18 Dynamic Properties of Types
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A.5.18.1 Data Location
+++++++++++++++++++++++
 
 1.  The ``DW_AT_data_location`` attribute may be used with any type that
     provides one or more levels of hidden indirection and/or run-time parameters
     in its representation. Its value is a DWARF operation expression E which
     computes the location description of the data for an object. When this
     attribute is omitted, the location description of the data is the same as
     the location description of the object.
 
3.  ``DW_CFA_LLVM_def_aspace_cfa`` *New*
     of evaluating the DWARF operation expression ``DW_OP_constu AS;
     DW_OP_LLVM_aspace_bregx R, B`` as a location description.
 
     If AS is not one of the values defined by the target architecture specific
     ``DW_ASPACE_*`` values then the DWARF expression is ill-formed.
 
 4.  ``DW_CFA_LLVM_def_aspace_cfa_sf`` *New*
 
-    The ``DW_CFA_def_cfa_sf`` instruction takes three operands: an unsigned
-    LEB128 value representing a register number R, a signed LEB128 factored byte
-    displacement B, and an unsigned LEB128 value representing a target
-    architecture specific address space identifier AS. The required action is to
-    define the current CFA rule to be the result of evaluating the DWARF
-    operation expression ``DW_OP_constu AS; DW_OP_LLVM_aspace_bregx R,
-    B * data_alignment_factor`` as a location description.
+    The ``DW_CFA_LLVM_def_aspace_cfa_sf`` instruction takes three operands: an
+    unsigned LEB128 value representing a register number R, a signed LEB128
+    factored byte displacement B, and an unsigned LEB128 value representing a
+    target architecture specific address space identifier AS. The required
+    action is to define the current CFA rule to be the result of evaluating the
+    DWARF operation expression ``DW_OP_constu AS; DW_OP_LLVM_aspace_bregx R, B *
+    data_alignment_factor`` as a location description.
 
     If AS is not one of the values defined by the target architecture specific
     ``DW_ASPACE_*`` values, then the DWARF expression is ill-formed.
 
     *The action is the same as* ``DW_CFA_aspace_def_cfa``\ *, except that the
     second operand is signed and factored.*
 
 5.  ``DW_CFA_def_cfa_register``