diff --git a/006-editorial.txt b/006-editorial.txt index c983e58..1f426cb 100644 --- a/006-editorial.txt +++ b/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 diff --git a/010-generalize-offsetting.txt b/010-generalize-offsetting.txt index 316b3bb..2f15843 100644 --- a/010-generalize-offsetting.txt +++ b/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 diff --git a/013-generalize-address-spaces.txt b/013-generalize-address-spaces.txt index 8efc7dc..14f032e 100644 --- a/013-generalize-address-spaces.txt +++ b/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 diff --git a/022-memory-spaces.txt b/022-memory-spaces.txt index ebc14c3..03d2a5a 100644 --- a/022-memory-spaces.txt +++ b/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 diff --git a/call-ref.txt b/call-ref.txt index 952c6e6..54611c9 100644 --- a/call-ref.txt +++ b/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 ----------