[Dwarf-discuss] ISSUE: vector types. V2

[Ben Woodard]

On 4/6/23 03:47, Metzger, Markus T wrote:
> Hello Jakub, Ben,
>
>> On Wed, Apr 05, 2023 at 07:16:35PM -0700, Ben Woodard via Dwarf-discuss wrote:
>>> To distinguish these vector types from regular C arrays, GCC's DWARF
>>> describes a vector type as an array with the DW_AT_GNU_vector
>>> attribute.  Clang also supports the GCC vector extensions, and
>>> describes the vector types in DWARF using the same attribute as GCC.
>>> Support for this DWARF extension has been implemented in GDB for well
>>> over a decade.
>>>
>>> Other languages have support for vector types, with similar ABI and/or
>>> API implications, and so DW_AT_GNU_vector is also used for languages
>>> beyond C/C++ today.
>>>
>>> This proposal standardizes the existing behavior.
>> I don't think this is a good idea, we should go for
>> DW_TAG_vector_type
>> instead IMHO.  DW_AT_GNU_vector used to be a good idea as an extension,
>> as mentioned the (generic) vector types are in many ways similar to arrays,
>> so even a DWARF consumer which doesn't understand DW_AT_GNU_vector could
>> handle the vector types sanely in some cases.
>> But as you also mention, vector types are in various ways different from
>> array types.  Not sure if supporting dimensions in the way which is done
>> for arrays is needed (I believe vector types are always one-dimensional
>> indexed from 0).  And we almost certainly want to allow vectors on DWARF
>> expression stack; I'd probably not make DW_TAG_vector_type a base type,
>> but extended the typed DWARF stack so that it can contain base types or
>> DW_TAG_vector_type of base types or something similar.
> Is there a limit to the length of such a vector type?

When it comes to CPUs and hardware vectors the architectural 
specification for aarch64 maxes out at 2048 bits (256 bytes). No current 
implementation that I am aware of goes beyond 512b though.

The RISC-V architecture RVV maxes out at 65536 bits (2^16 bits) which is 
8192 bytes.

I haven't done a survey of GPUs but in general they have HUGE register 
files in comparison to CPUs and this ends up meaning larger vectors or 
more vector registers or even matrix registers all of which can spill to 
memory or be loaded from memory. AIUI how these are organized into 
vectors or matrices is a tuning parameter in GPU design based upon the 
expected workload and how it interacts the memory subsystem.

When we are considering DWARF6 which will probably come out in 2024 and 
really start hitting tools in 2025 and will be around for a few years 
before DWARF7 even starts to be considered, I think we should anticipate 
hardware which will be available in the neighborhood of 2030. I wouldn't 
be surprised if there were steady growth in the size of hardware's 
register files between now and then. Furthermore, one of the things 
holding back development of the software backing AI running models and 
GPU based compute is programmer tooling (sorry, I am less familiar with 
graphics and game development) and DWARF is a big portion of that. So I 
think we need to design the standard to be a bit future proof in this area.

> Would the language
> define fixed-length vectors as special built-in types or is the goal to support
> arbitrary vector lengths?

I understand your concern. A consumer needs to know how much memory are 
you going to going need to allocate for each entry on the DWARF stack.

if we allow these types on the DWARF stack, then I think that this is 
going to be something determined by the target architecture, and 
expressed through the Platform Specific ABI for the architecture which 
includes the calling conventions. So I would say that for a supported 
target language and architecture, a consumer will need to allocate 
sufficient storage for the DWARF stack entries to contain whatever size 
of entries that can be put on the stack. I believe that topic is beyond 
the scope of DWARF in and of itself. It is more the a question of: does 
a particular consumer support a particular language on a particular 
architecture.

Personally, I'm not sure if these vector and matrix types need to be put 
on the DWARF stack. On one hand, I have Jakub whose opinion I regard 
very highly who says that they will need to be on the stack. And on the 
other hand I have Tony whose opinion I also regard very highly who says 
that they do not need to be on the stack. I personally have not been 
able to settle the disagreement in my mind for myself.

> It might be good to maintain an upper limit on the size of a stack entry.

Agreed -- but it isn't the 80's anymore. My development workstation has 
128GB of main memory and 16GB of VRAM. Even the massive 8kB needed for a 
full sized RISC-V RVV type is background noise and the maximum stack 
depth for any DWARF expression I've ever seen could still be counted on 
my hands. So I don't think things are likely to get too out of hand.

-ben


>
> Regards,
> Markus.
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>