[Dwarf-discuss] ISSUE: vector types. V2

[Ben Woodard]

I believe that all three points that you bring up here are correct and I 
will fix them in V3 of my proposal.


On 4/6/23 03:44, Metzger, Markus T wrote:
> 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
>> locations.
>> - 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.
>
> 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