From c34fdd875166f3441d5e037dfff081b1cb14920c Mon Sep 17 00:00:00 2001 From: Tony Tye Date: Thu, 19 Jan 2023 22:42:16 -0500 Subject: [PATCH] Clarify generalize offset proposal List register, composite and implicit location storage as examples of arbitrary sized storage. Addresses issue #65. Add transition paragraph as proposed in issue #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 | 2 +- 010-generalize-offsetting.txt | 22 ++++++++++++---------- 013-generalize-address-spaces.txt | 13 +++++++++---- 022-memory-spaces.txt | 9 +++++---- call-ref.txt | 5 +++-- 5 files changed, 30 insertions(+), 21 deletions(-) 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..a3bed1c 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, 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 ----------