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


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:

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_tensor A 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_tensor attribute, 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_tensor is present, the element type must be a DW_TAG_base_type entry.

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_tensor 0xNN flag

2023-06-07: Revised

2023-11-02: Revised phrasing; added DW_TAG_base_type restriction.

2023-11-13: Accepted.