[Dwarf-discuss] ISSUE: tensor types. V3
Cary Coutant
ccoutant@gmail.com
Wed Apr 19 02:03:54 GMT 2023
Added as Issue 230413.1:
https://dwarfstd.org/issues/230413.1.html
-cary
On Thu, Apr 13, 2023 at 11:57 AM Ben Woodard via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Here is V3 of what was my vector types proposal.
>
> Changes since V2:
>
> We discussed this extensively in the DWARF for GPUs meeting. Cary
> originally wanted it to be a TAG rather than an attribute on an array and
> quite frankly, I don't care and so my default position is "What Cary wants,
> Cary gets". However, Pedro pointed out LLVMs different flavors of vector
> types which like the vector types bubbled up from the target architecture
> to language source through intrinsics. Each of these different vectors
> flavors has slightly different semantics. There is a really nice table on
> https://clang.llvm.org/docs/LanguageExtensions.html#id15 that summarizes
> the differences. This changed the course of discussion and it seemed that
> the group moved back to making it an attribute on an array. Since there are
> multiple flavors of vector, this led to adding a parameter to the attribute
> that defines the flavor and a table which defines what those constants mean.
>
> I brought up the point about matrix registers. Jakub is right there are
> currently no compilers which make use of matrix vector types right now.
> Even AMD's GPUs which do have intrinsics for matrix operations end up
> implementing them with arrays of vector registers. This area is rapidly
> evolving due to its heavy use in HPC and AI. The challenge appears to be
> the compilers haven't supported these operations yet. Cary came up with the
> idea of calling it a "tensor" rather than defining DW_AT_vector and then
> later adding DW_AT_matrix. So through the entire document, vector has been
> changed to tensor.
>
> Markus pointed out a few problems in my V2 version, I tried to address
> those. They were pretty minor and obvious. Markus please verify that I did
> it to your satisfaction otherwise V4.
>
> What has not changed since V2:
>
> I didn't put back any changes that would allow these tensor types to
> appear on the DWARF stack. I feel that particular topic hasn't been settled
> yet. The general plan is I will work with Jakub and create some cases where
> a compiler could want to put these vector types on the DWARF stack. Tony
> Tye and the AMD team believe that the vector types do not need to be on the
> stack and believe that all the cases where the debuggers would want to
> access elements within the vector can be addressed with offsetting. IIUC a
> key point seems to be that they have never seen a case where an induction
> variable was embedded in a slot in a vector register, it always is a
> scalar. (I am not sure that I fully grokked their argument -- so please
> correct me) In the cases where it was, it could still be accessed as an
> implicit. Once I've got some examples of how a debugger might want to put
> vector types on the DWARF stack, the AMD team can suggest alternative
> approaches. I said that I would make a V4 proposal if the group ultimately
> comes to a consensus that vector registers are in fact needed on the stack.
>
> As for DWARF consumers, according to Cary, the reason why DWARF operations
> are currently limited to base types is to make it relatively easy on the
> consumers. If vector registers are in fact needed on the stack, Zoran is
> fairly certain that changes that he's preparing to enable gdb to support
> GPUs would also automatically handle vector registers on the stack. The
> problem for gdb would be client server operation with gdbserver. The goal
> with gdbserver has been to keep its execution footprint very small. While
> having huge registers on the DWARF stack is reasonable when gdb is
> operating on the target or on the client side, on the server end it may
> pose a problem. John DelSignore said that TotalView has a similar concern
> because of its client server architecture. He did point out though that
> DWARF expressions are ephemeral.
>
> My impression was that Cary wanted to add this tensor types issue to the
> DWARF issue queue for discussion and once question of vector registers on
> the stack is settled, this proposal can be amended or a new proposal
> addressing just that issue can be filed.
> ------------------------------
> Tensor 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.
>
> 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.
>
> 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 with an argument that specifies the
> flavor of type it is.
>
> 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 whose integer constant, will specify the
> kind of tensor it is. The default type of tensor shall be the kind
> used by the vector registers in the target architecture.
>
> Table 5.4: Tensor attribute values
> ------------------------------------------------------------------
> Name | Meaning
> ------------------------------------------------------------------
> DW_TENSOR_default | Default encoding and semantics used by target
> | architecture's vector registers
> DW_TENSOR_boolean | Boolean vectors map to vector mask registers.
> DW_TENSOR_opencl | OpenCL vector encoding and semantics
> DW_TENSOR_neon | NEON vector encoding and semantics
> DW_TENSOR_sve | SVE vector encoding and semantics
> ------------------------------------------------------------------
>
> 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.
> --------------------------------------------------------------------
>
> A table shall be added to chapter 7 defining these tensor types and
> giving these attributes numerical values. Something like:
>
> --------------------------------------------------------------------
> 7.N Tensor types
>
> The encodings of the constants used in DW_AT_tensor attribute are
> given in table 7.N.
>
> Table 7.N: Tensor type encoding
> ---------------------------
> Name | Value
> ---------------------------
> DW_TENSOR_default | 0x00
> DW_TENSOR_boolean | 0x01
> DW_TENSOR_opencl | 0x02
> DW_TENSOR_neon | 0x03
> DW_TENSOR_sve | 0x04
> ---------------------------
>
> --------------------------------------------------------------------
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20230418/999580da/attachment-0001.htm>
More information about the Dwarf-discuss
mailing list