Clarify generalize offset proposal

List register, composite and implicit location storage as examples of
arbitrary sized storage. Addresses issue ccoutant#65.

Add transition paragraph as proposed in issue ccoutant#66.

Correct section reference in the editorial part.

Clarify address space and memory space proposals.

Update title of call-ref.txt to reflect that it also corrects DW_OP_implicit_pointer.

006-editorial.txt

@@ -8,7 +8,7 @@ does not make any substantive changes.
 BACKGROUND
 ----------
 
-With the changes proposed in Part 6 of this series, DWARF expressions
+With the changes proposed in Part 5 of this series, DWARF expressions
 and location descriptions have essentially been unified, and the
 distinction between the two is no longer material. The bulk of this
 proposal merely reorganizes the text from Sections 2.5 (DWARF

010-generalize-offsetting.txt

@@ -32,17 +32,19 @@ address integral type value would be required. Keeping a separation of location
 description operations and arithmetic operations avoids this semantic
 complexity.
 
+The offset operators are designed to address four specific problems.
+
 The offset operations can operate on location storage of any size. For example,
-implicit location storage could be any number of bits in size. It is simpler to
-define offsets that exceed the size of the location storage as being an
-evaluation error, than having to force an implementation to support potentially
-infinite precision offsets to allow it to correctly track a series of positive
-and negative offsets that may transiently overflow or underflow, but end up in
-range. This is simple for the arithmetic operations as they are defined in
-terms of two's compliment arithmetic on a base type of a fixed size. Therefore,
-the offset operation define that integer overflow is ill-formed. This is in
-contrast to the DW_OP_plus, DW_OP_plus_uconst, and DW_OP_minus arithmetic
-operations which define that it causes wrap-around.
+register, composite, and implicit location storage could be any number of bits
+in size. It is simpler to define offsets that exceed the size of the location
+storage as being an evaluation error, than having to force an implementation to
+support potentially infinite precision offsets to allow it to correctly track a
+series of positive and negative offsets that may transiently overflow or
+underflow, but end up in range. This is simple for the arithmetic operations as
+they are defined in terms of two's compliment arithmetic on a base type of a
+fixed size. Therefore, the offset operation defines that integer overflow is
+ill-formed. This is in contrast to the DW_OP_plus, DW_OP_plus_uconst, and
+DW_OP_minus arithmetic operations which define that it causes wrap-around.
 
 Having the offset operations allows DW_OP_push_object_address to push a
 location description that may be in a register, or be an implicit value. The

013-generalize-address-spaces.txt

@@ -15,10 +15,15 @@ that can only be put on complete objects, such as a variable. That makes it only
 suitable for describing an entity (such as variable or subprogram code) that is
 in a single kind of memory.
 
-Therefore, AMDGPU uses the DWARF concept of address spaces. For example, a
-variable may be allocated in a register that is partially spilled to the call
-stack which is in the private address space, and partially spilled to the local
-address space.
+AMDGPU uses multiple address spaces. For example, a variable may be allocated in
+a register that is partially spilled to the call stack which is in the private
+address space, and partially spilled to the local address space. DWARF mentions
+address spaces, for example as an argument to the DW_OP_xderef* operations. A
+new section that defines address classes is added.
+
+A new attribute DW_AT_address_space is added to pointer and reference types.
+This allows the compiler to specify which address space is being used to
+represent the pointer or reference type.
 
 DWARF 5 uses the concept of an address in many expression operations but does
 not define how it relates to address spaces. For example,
@@ -39,7 +44,7 @@ address space. For example, AMDGPU variables can be allocated in the local
 address space at a fixed address.
 
 A DW_OP_form_aspace_address operation is added and defined to create a memory
-location description from an address and address space. If can be used to
+location description from an address and address space. It can be used to
 specify the location of a variable that is allocated in a specific address
 space. This allows the size of addresses in an address space to be larger than
 the generic type. It also allows a consumer great implementation freedom. It

022-memory-spaces.txt

@@ -3,11 +3,12 @@ Part 18: Support for Source Language Memory Spaces
 PROBLEM DESCRIPTION
 
 AMDGPU supports languages, such as OpenCL, that define source language memory
-classes. Support is added to define language specific memory spaces so they
-can be used in a consistent way by consumers.
+classes. Support is added to define language specific memory spaces so they can
+be used in a consistent way by consumers.
 
-Support for using memory spaces in defining source language types and data
-object allocation is also added.
+A new attribute DW_AT_memory_space is added to support using memory spaces in
+defining source language pointer and reference types and data object
+allocation.
 
 PROPOSAL
 

call-ref.txt

@@ -1,7 +1,8 @@
-DW_OP_call_ref Correction
+DW_OP_call_ref & DW_OP_implicit_pointer Correction
 
 Section 2.5.1.5 (Control Flow Operations), page 36, lines 15-19
-
+Section 2.6.1.1.4 (Implicit Location Descriptions), page 41
+Section 7.5.5 (Classes and Forms), on page 217
 
 BACKGROUND
 ----------