[Dwarf-discuss] ISSUE: tensor types. V4

[Ben Woodard]

This is my long overdue revision my vector types proposal. The main 
difference is Todd Allen and Markus Metzger together convinced me that 
adding flavors to the tensor attributes were not needed. It should 
replace the current proposal https://dwarfstd.org/issues/230413.1.html

Tensor types

Some compilers 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.

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.

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.

Support for this DWARF extension has been implemented in GDB for well
over a decade.

Other vendor's compilers have similar C/C++ extensions.  For example,
Motorola’s Altivec C/C++ Language Extensions, which predates GCC's
extensions.

Clang also supports the GCC vector extensions, and in some cases
describes the vector types in DWARF using the same attribute as
GCC. However, clang also supports many other types of vectors with
somewhat different semantics than those used by GCC.

https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors

In the process of refining this proposal, we debated whether this
proposal should be a tag like DW_TAG_vector or if it should be an
attribute applied to an array. It was clang's various flavors of
vectors with different semantics which ultimately led to the current
proposal where it is an atribute. While the different flavors of
vectors that clang supports are not sufficiently different to require
an argument defining different flavors a flag attribute can easily be
extended to accept a constant class if the need should ever arise.

It should be noted that one of the more challenging types of vector
for DWARF to deal with are variable vector lengths which are
implementation specific on a per core basis rather than specified in
the target architecture. It was thought that this may require a new
flavor of vector type. However, in at least one case ARM's SVE, these
challenges were addressed by moving the complexity out of DWARF and
providing a pseudo register in the runtime environment that specifies
the length of the vector.

https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst#dwarf-register-names

During the course of the discussion, it was pointed out that while no
compiler currently supports matrix types, there are several current
processors which have matrix registers that have intrinsics that allow
a programmer to access them. One example is AMD's second generation
CDNA processors and later.

https://gpuopen.com/learn/amd-lab-notes/amd-lab-notes-matrix-cores-readme/

Rather than introducing a second new attribute like DW_AT_matrix, we
thought that calling the attribute DW_AT_tensor was correct and
general enough to embrace the concept.

-------------------------------------------------

In Section 2.2 Attribute Types, DW_AT_tensor shall be added to Table 2.2

--------------------------------------------------------------------
     DW_AT_tensor                | A language tensor type
--------------------------------------------------------------------

The hyperlink in the "Identifies or Specifies" column shall point to
the paragraph added to Section 5.5 below for DW_AT_tensor.

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 a short single dimension array but have different
     encoding, a different calling convention and different arithmatic
     and logical operational semantics than the source language
     arrays. Likewise a few architectures are starting to add matrix
     register types with similar variations in encoding and semantics
     from normal source language array types.
--------------------------------------------------------------------

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 or matrix type, shall be
     denoted with DW_AT_tensor. The width and when applicable the
     number of rows of the type shall be specified as array
     dimensions. The type contained within the tensor array type must
     be a DW_TAG_base_type entry.
--------------------------------------------------------------------

An entry shall be added to the table of attributes in 7.5.4 defining 
this new attribute.
giving this attribute a value. Something like:

--------------------------------------------------------------------
     Table 7.5
     -----------------------------------
     Attribute Name    | Value | Classes
     -----------------------------------
     DW_AT_tensor      | 0xNN  | flag
     -----------------------------------

--------------------------------------------------------------------