[Dwarf-Discuss] modeling different address spaces

[Todd Allen]

Markus,

My experience with an architecture like this also is a GPU: the Nvidia CUDA
GPUs.  I don't work on nvcc.  I'm coming at this from the consumer side.  But
what I've observed:

They use DW_AT_address_class with a CUDA-specific enum of address spaces, with
values for things like: global memory, shared memory, const memory, etc.  They
don't attach these attributes to subroutines, because all the code on that
architecture is in a single "code" memory.  They do attach them to pointer
types, as the DWARF spec describes.  They also attach them to variables,
formals, etc.  That's a vendor extension (which I'd forgotten until I looked it
up again in the DWARF spec).  But an obvious one.  We might want to formalize it
at some point.

Anyway, these are the sorts of things we see:

   DW_TAG_pointer_type
      DW_AT_type          : ...
      DW_AT_address_class : ptxGenericStorage

   DW_TAG_variable
      DW_AT_name          : myConstant
      DW_AT_type          : ...
      DW_AT_location      : ...
      DW_AT_address_class : ptxConstStorage

   DW_TAG_variable
      DW_AT_abstract_origin : ...
      DW_AT_location        : ...
      DW_AT_address_class   : ptxLocalStorage

I don't know your architecture, but I'd expect something similar to work for any
GPU with heterogeneous memories.

-- 
Todd Allen
Concurrent Real-Time

On Mon, Jul 20, 2020 at 08:31:53AM +0000, Dwarf Discussion wrote:
> Hello Michael,
> 
> > > What would be the recommended way to model variables that are allocated
> > > to different address spaces?
> > 
> > Can you describe the architecture a bit?
> 
> It's a GPU.  It uses a different address space for shared local memory.
> 
> 
> > > I found DW_OPT_xderef for dereferencing address-space qualified pointers
> > > but the resulting memory location description wouldn???t have an
> > > address-space qualifier.
> > 
> > DW_OPT_xderef translates from an architecturally defined memory
> > reference including an address space into a linear address space
> > (generic type).  DWARF doesn't support computations on address-space
> > qualified addresses, although using a typed stack, this could be an
> > extension.
> 
> I don't see a need for this, right now.  It should suffice to describe that an
> object lives in address-space A so the location expression yields an A-address.
> 
> In another email you said: "
>     CUDA address spaces or a DSP with multiple distinct address spaces are 
>     what would conventionally be described as segmented memory.  I think 
>     that using the DW_AT_address_space would be reasonable.
> ".
> 
> I assume you mean DW_AT_address_class.  This should do the trick.  I just wasn't
> sure if that's the intended use of that attribute.
> 
> 
> > > I found DW_AT_address_class, which allows attaching an integer, which
> > > could represent the address-space.? This sounds pretty close.? I???m a bit
> > > thrown off by the example, though.
> > 
> > Which example?
> 
> Table 2.7 "Example address class codes" on p. 48.  It uses DW_AT_address_class
> to describe addressing modes.
> 
> Regards,
> Markus.
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Gary Kershaw
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org