[Dwarf-discuss] ISSUE: vector types. V2

Metzger, Markus T markus.t.metzger@intel.com
Thu Apr 6 10:44:32 GMT 2023

Hello Ben,

>This is version 2 of my vector types submission.
>Differences from V1:
>- Made the submission about vector types rather than vector registers.
>- Substituted Pedro's much better introduction for my own with minor edits.
>- Removed the modifications to the DWARF Stack. The AMD people like
>Pedro and Tony have been working on vector registers and vector types
>for a long time and they do not know of a good reason why we need the
>capability to a vector register on the DWARF stack. So I'm dropping that
>part. Furthermore, I could not find any evidence in code that uses the
>vector types that they needed to put vector types on the DWARF stack for
>- Removed the variable vector length attribute. This was not existing
>behavior. I'm fairly certain something like that is going to be
>necessary but it doesn't need to be in this submission.
>Vector types
>Some languages support vector data types, which are not possible to
>represent today in standard DWARF.  A vector is an array of values.
>These can be allocated to a SIMD vector register, if available, either
>permanently or temporarily, and operations on vectors make use of SIMD
>instructions, again if available.
>For example, as an extension to C and C++, GCC supports defining
>vector data types as described here:
>   https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
>In this C/C++ extension, vector types are similar to arrays, and you
>can index and initialize them similarly, but they have some important
>differences.  For example:
>- C arrays automatically decay to pointers.  Vector types do not.
>- Vector types can be passed by value to functions, and likewise
>   functions can return vector types by value. Neither of which can be
>   done with C arrays.
>- Vector types can be used with a subset of normal C operations: +, -,
>   *, /, unary minus, ^, |, &, ~, %.  For example, addition is defined as
>   the addition of the corresponding elements of the operands.
>A debugger that supports C/C++ expression evaluation will want to be
>able to support these vector operations on vector objects too.
>Vector types appear on function prototypes, so they have their own
>mangling scheme in the Itanium ABI.
>Other vendors have similar C/C++ extensions.  For example, Motorola’s
>Altivec C/C++ Language Extensions, which predates GCC's extensions.
>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.
>In Section 2.2 Attribute Types, DW_AT_vector and
>DW_AT_variable_vector_width shall be added to Table 2.2
>     DW_AT_vector                | A hardware vector type

Why hardware and not language?  I thought the proposal was changed
to model language vector types.

>The hyperlink in the "Identifies or Specifies" column shall point to
>the paragraph added to Section 5.5 below for DW_AT_vector.
>In Section 5.5 Array Type Entries, replace first paragraph of
>non-normative text with:
>     [non-normative] Many languages share the concept of an “array,”
>     which is a table of components of identical type. Furthermore,
>     many architectures contain vector types which mirror the
>     language concept of an array.

This isn't clear to me, but this is probably a consequence of defining
the attribute as hardware vector type.

>Insert the following paragraph between the first paragraph of
>normative text describing DW_TAG_array_type and the second paragraph
>dealing with multidimensional ordering.
>     An array type that refers to a vector type, shall be denoted with
>     DW_AT_vector. The the width of the type shall be specified as an
>     array dimension and the type contained within the register must be
>     a DW_TAG_base_type entry.

This is still referring to a register.


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

More information about the Dwarf-discuss mailing list