<div dir="ltr">Added as Issue 230413.1:<div><br></div><div><a href="https://dwarfstd.org/issues/230413.1.html">https://dwarfstd.org/issues/230413.1.html</a><br></div><div><br></div><div>-cary</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 13, 2023 at 11:57 AM Ben Woodard via Dwarf-discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org">dwarf-discuss@lists.dwarfstd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Here is V3 of what was my vector types proposal.</p>
<p>Changes since V2:<br>
</p>
<p>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
<a href="https://clang.llvm.org/docs/LanguageExtensions.html#id15" target="_blank">https://clang.llvm.org/docs/LanguageExtensions.html#id15</a> 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.<br>
</p>
<p>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. <br>
</p>
<p>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.<br>
</p>
<p>What has not changed since V2:</p>
<p>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.</p>
<p>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.</p>
<p>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.
<br>
</p>
<hr width="100%" size="2"><font face="monospace">Tensor types<br>
<br>
Some languages support vector data types, which are not possible
to<br>
represent today in standard DWARF. A vector is an array of
values.<br>
These can be allocated to a SIMD vector register, if available,
either<br>
permanently or temporarily, and operations on vectors make use of
SIMD<br>
instructions, again if available.<br>
<br>
For example, as an extension to C and C++, GCC supports defining<br>
vector data types as described here:<br>
<br>
<a href="https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html" target="_blank">https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html</a><br>
<br>
In this C/C++ extension, vector types are similar to arrays, and
you<br>
can index and initialize them similarly, but they have some
important<br>
differences. For example:<br>
<br>
- C arrays automatically decay to pointers. Vector types do not.<br>
<br>
- Vector types can be passed by value to functions, and likewise<br>
functions can return vector types by value. Neither of which can
be<br>
done with C arrays.<br>
<br>
- Vector types can be used with a subset of normal C operations:
+, -,<br>
*, /, unary minus, ^, |, &, ~, %. For example, addition is
defined as<br>
the addition of the corresponding elements of the operands.<br>
<br>
A debugger that supports C/C++ expression evaluation will want to
be<br>
able to support these vector operations on vector objects too.<br>
<br>
Vector types appear on function prototypes, so they have their own<br>
mangling scheme in the Itanium ABI.<br>
<br>
Other vendors have similar C/C++ extensions. For example,
Motorola’s<br>
Altivec C/C++ Language Extensions, which predates GCC's
extensions.<br>
<br>
To distinguish these vector types from regular C arrays, GCC's
DWARF<br>
describes a vector type as an array with the DW_AT_GNU_vector<br>
attribute.<br>
<br>
Support for this DWARF extension has been implemented in GDB for
well<br>
over a decade.<br>
<br>
Other languages have support for vector types, with similar ABI
and/or<br>
API implications, and so DW_AT_GNU_vector is also used for
languages<br>
beyond C/C++ today.<br>
<br>
Clang also supports the GCC vector extensions, and in some cases<br>
describes the vector types in DWARF using the same attribute as<br>
GCC. However, clang also supports many other types of vectors with<br>
somewhat different semantics than those used by GCC.<br>
<br>
<a href="https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors" target="_blank">https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors</a><br>
<br>
In the process of refining this proposal, we debated whether this<br>
proposal should be a tag like DW_TAG_vector or if it should be an<br>
attribute applied to an array. It was clang's various flavors of<br>
vectors with different semantics which ultimately led to the
current<br>
proposal where it is an atribute with an argument that specifies
the<br>
flavor of type it is.<br>
<br>
During the course of the discussion, it was pointed out that while
no<br>
compiler currently supports matrix types, there are several
current<br>
processors which have matrix registers that have intrinsics that
allow<br>
a programmer to access them. One example is AMD's second
generation<br>
CDNA processors and later.<br>
<br>
<a href="https://gpuopen.com/learn/amd-lab-notes/amd-lab-notes-matrix-cores-readme/" target="_blank">https://gpuopen.com/learn/amd-lab-notes/amd-lab-notes-matrix-cores-readme/</a><br>
<br>
Rather than introducing a second new attribute like DW_AT_matrix,
we<br>
thought that calling the attribute DW_AT_tensor was correct and<br>
general enough to embrace the concept.<br>
<br>
-------------------------------------------------<br>
<br>
In Section 2.2 Attribute Types, DW_AT_tensor shall be added to
Table 2.2<br>
<br>
--------------------------------------------------------------------<br>
DW_AT_tensor | A language tensor type<br>
--------------------------------------------------------------------<br>
<br>
The hyperlink in the "Identifies or Specifies" column shall point
to<br>
the paragraph added to Section 5.5 below for DW_AT_tensor.<br>
<br>
In Section 5.5 Array Type Entries, replace first paragraph of<br>
non-normative text with:<br>
<br>
--------------------------------------------------------------------<br>
[non-normative] Many languages share the concept of an
“array,”<br>
which is a table of components of identical type. Furthermore,<br>
many architectures contain vector types which mirror the
language<br>
concept of a short single dimension array but have different<br>
encoding, a different calling convention and different
arithmatic<br>
and logical operational semantics than the source language<br>
arrays. Likewise a few architectures are starting to add
matrix<br>
register types with similar variations in encoding and
semantics<br>
from normal source language array types.<br>
--------------------------------------------------------------------<br>
<br>
Insert the following paragraph between the first paragraph of<br>
normative text describing DW_TAG_array_type and the second
paragraph<br>
dealing with multidimensional ordering.<br>
<br>
--------------------------------------------------------------------<br>
An array type that refers to a vector or matrix type, shall be<br>
denoted with DW_AT_tensor whose integer constant, will specify
the<br>
kind of tensor it is. The default type of tensor shall be the
kind<br>
used by the vector registers in the target architecture.<br>
<br>
Table 5.4: Tensor attribute values<br>
------------------------------------------------------------------<br>
Name | Meaning<br>
------------------------------------------------------------------<br>
DW_TENSOR_default | Default encoding and semantics used by
target<br>
| architecture's vector registers<br>
DW_TENSOR_boolean | Boolean vectors map to vector mask
registers.<br>
DW_TENSOR_opencl | OpenCL vector encoding and semantics<br>
DW_TENSOR_neon | NEON vector encoding and semantics<br>
DW_TENSOR_sve | SVE vector encoding and semantics<br>
------------------------------------------------------------------<br>
<br>
The width and when applicable the number of rows of the type<br>
shall be specified as array dimensions. The type contained<br>
within the tensor array type must be a DW_TAG_base_type entry.<br>
--------------------------------------------------------------------<br>
<br>
A table shall be added to chapter 7 defining these tensor types
and<br>
giving these attributes numerical values. Something like:<br>
<br>
--------------------------------------------------------------------<br>
7.N Tensor types<br>
<br>
The encodings of the constants used in DW_AT_tensor attribute
are<br>
given in table 7.N.<br>
<br>
Table 7.N: Tensor type encoding<br>
---------------------------<br>
Name | Value<br>
---------------------------<br>
DW_TENSOR_default | 0x00<br>
DW_TENSOR_boolean | 0x01<br>
DW_TENSOR_opencl | 0x02<br>
DW_TENSOR_neon | 0x03<br>
DW_TENSOR_sve | 0x04<br>
---------------------------<br>
<br>
--------------------------------------------------------------------</font><br>
<br>
</div>
-- <br>
Dwarf-discuss mailing list<br>
<a href="mailto:Dwarf-discuss@lists.dwarfstd.org" target="_blank">Dwarf-discuss@lists.dwarfstd.org</a><br>
<a href="https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss" rel="noreferrer" target="_blank">https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss</a><br>
</blockquote></div>