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
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
