General Support for Address Spaces

AMDGPU needs to be able to describe addresses that are in different kinds of
memory. Optimized code may need to describe a variable that resides in pieces
that are in different kinds of storage which may include parts of registers,
memory that is in a mixture of memory kinds, implicit values, or be undefined.

DWARF 5 has the concept of segment addresses. However, the segment cannot be
specified within a DWARF expression, which is only able to specify the offset
portion of a segment address. The segment index is only provided by the entity
that specifies the DWARF expression. Therefore, the segment index is a property
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.

DWARF 5 uses the concept of an address in many expression operations but does
not define how it relates to address spaces. For example,
DW_OP_push_object_address pushes the address of an object. Other contexts
implicitly push an address on the stack before evaluating an expression. For
example, the DW_AT_use_location attribute of the DW_TAG_ptr_to_member_type. The
expression belongs to a source language type which may apply to objects
allocated in different kinds of storage. Therefore, it is desirable that the
expression that uses the address can do so without regard to what kind of
storage it specifies, including the address space of a memory location
description. For example, a pointer to member value may want to be applied to an
object that may reside in any address space.

The DWARF 5 DW_OP_xderef* operations allow a value to be converted into an
address of a specified address space which is then read. But it provides no way
to create a memory location description for an address in the non-default
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
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
allows the implicit conversion back to a value to be limited only to the default
address space to maintain compatibility with DWARF 5. For other address spaces
the producer can use the new operations that explicitly specify the address
space.

In contrast, if the DW_OP_form_aspace_address operation had been defined to
produce a value, and an implicit conversion to a memory location description was
defined, then it would be limited to the size of the generic type (which matches
the size of the default address space). An implementation would likely have to
use <i>reserved ranges</i> of value to represent different address spaces. Such
a value would likely not match any address value in the actual hardware. That
would require the consumer to have special treatment for such values.

DW_OP_breg* treats the register as containing an address in the default address
space. A DW_OP_aspace_bregx operation is added to allow the address space of the
address held in a register to be specified.

Similarly, DW_OP_implicit_pointer treats its implicit pointer value as being in
the default address space. A DW_OP_aspace_implicit_pointer operation is added to
allow the address space to be specified.

Almost all uses of addresses in DWARF 5 are limited to defining location
descriptions, or to be dereferenced to read memory. The exception is
DW_CFA_val_offset which uses the address to set the value of a register. In
order to support address spaces, the CFA DWARF expression is defined to be a
memory location description. This allows it to specify an address space which is
used to convert the offset address back to an address in that address space.

This approach of extending memory location descriptions to support address
spaces, allows all existing DWARF 5 expressions to have the identical semantics.
It allows the compiler to explicitly specify the address space it is using. For
example, a compiler could choose to access private memory in a swizzled manner
when mapping a source language thread to the lane of a wavefront in a SIMT
manner. Or a compiler could choose to access it in an unswizzled manner if
mapping the same language with the wavefront being the thread.

It also allows the compiler to mix the address space it uses to access private
memory. For example, for SIMT it can still spill entire vector registers in an
unswizzled manner, while using a swizzled private memory for SIMT variable
access.

This approach also allows memory location descriptions for different address
spaces to be combined using the regular DW_OP_*piece operations.

Location descriptions are an abstraction of storage. They give freedom to the
consumer on how to implement them. They allow the address space to encode lane
information so they can be used to read memory with only the memory location
description and no extra information. The same set of operations can operate on
locations independent of their kind of storage. The DW_OP_deref* therefore can
be used on any storage kind, including memory location descriptions of different
address spaces. Therefore, the DW_OP_xderef* operations are unnecessary, except
to become a more compact way to encode a non-default address space address
followed by dereferencing it.