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