Issue 230413.1: Tensor Types
| Author: | Ben Woodard |
|---|---|
| Champion: | Zoran Zaric |
| Date submitted: | 2023-04-13 |
| Date revised: | 2023-11-09 |
| Date closed: | 2023-11-13 |
| Type: | Enhancement |
| Status: | Accepted |
| DWARF Version: | 6 |
Background
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.
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.
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.
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.
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.
Proposed Changes
In Section 2.2 Attribute Types, add a DW_AT_tensor attribute entry to
Table 2.2:
Attribute Usage DW_AT_tensorA language tensor type
The hyperlink in the “Identifies or Specifies” column needs to 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 arithmetic 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.
The array type may have a
DW_AT_tensorattribute, which is a flag. If present, this attribute indicates that the entry describes a vector or matrix type. The array dimensions (see below) describe the vector width, and when applicable the number of rows.
Append a new sentence to the paragraph talking about DW_AT_type (p.111,
lines 21-22):
If
DW_AT_tensoris present, the element type must be aDW_TAG_base_typeentry.
Add an entry to the table of attributes (Table 7.5) in Section 7.5.4 giving this attribute a value:
Attribute Name Value Classes DW_AT_tensor0xNN flag
2023-06-07: Revised
2023-11-02: Revised phrasing; added DW_TAG_base_type restriction.
2023-11-13: Accepted.
