<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I was working on this before the change of administration. <br>
</p>
<p>Vector types have been around for a very long time and compilers
use them but are not handled in the DWARF standard right on
DWARF5. I think that this was basically something that was
overlooked and no one filed an issue to get it addressed in the
standard. <br>
</p>
<p>There are two different proposals about how to handle them and I
believe that the committee should discuss the two options and then
decide a course of action.</p>
<p>At the bottom of this email is my proposal. I will admit that in
its current state it is a work in progress. My original intent was
to simply codify the existing behavior as implemented by GCC and
LLVM (and probably other compilers) moving it from a vendor
attribute to something that was in the standard. However, at the
time I was working with Tony Tye and the people at AMD on one of
their proposals toto better support GPUs and this involved a lot
of work on the DWARF stack and the operations done within them.
This led me to realize a problem with my initial proposal and that
was that it didn't consider the impacts on the DWARF stack
operations. I reworked my proposal to include changes in that area
of the standard. Essentially it adds language to all operations
that were limited to a base type now would also work on a vector
type of a base type. Tony raised an objection to this and argued
that handling vector types on the DWARF stack was not necessary. I
have not put in the time to really come up with a counter example
to that assertion. He may be correct. I'm personally not sure. No
current compiler that I am aware of actually generates DWARF that
makes use of the DWARF stack with vector types. My intuition is
that there may be a case related to scatter gather where it could
be useful to make use vector registers on the DWARF stack.</p>
<p>Tony Tye has a different proposal.
<a class="moz-txt-link-freetext" href="https://github.com/t-tye/dwarf-locations/blob/main/014-vector-base-types.txt">https://github.com/t-tye/dwarf-locations/blob/main/014-vector-base-types.txt</a>
</p>
<p>His proposal basically amounts to make vector types base types. I
can't say that I disagree with that overall approach. My concerns
are:</p>
<ol>
<li>It breaks with existing behavior.</li>
<li>It would greatly increase the number of base types for a
platform. I think that it would be the combinatorial expansion
of all the available encodings and the architecture's available
vector lengths.<br>
</li>
<li>There is an interaction between the Platform Specific ABI and
the base types for an architecture. I'm not sure but I think
that the PS ABI for the various architectures might need
revision given this change. Given how many architectures there
are<br>
</li>
<li>It would immediately allow the large vector registers on the
DWARF stack and I fear that some DWARF stack implementations
which are currently based on a platform's size of an INT would
break. Some architecture's vector registers could be as large as
2048b.</li>
<li>I don't know how it will deal with hardware implementation
variable vector lengths like ARM's SVE or RISC-V RVV. Just for
reference for people who may not know this is a quick intro to
SVE
<a class="moz-txt-link-freetext" href="https://www.stonybrook.edu/commcms/ookami/support/_docs/3%20-%20Intro%20to%20SVE.pdf">https://www.stonybrook.edu/commcms/ookami/support/_docs/3%20-%20Intro%20to%20SVE.pdf</a><br>
</li>
</ol>
<p>Anyway, my biggest concern is that in the DWARF6 process vector
register types get standardized. In general I have come to respect
Tony as a very thoughtful architect, so I would not be upset if
his proposal were accepted over mine. I would just like to make
sure that the concerns that I've pointed out above are considered.<br>
</p>
<p>----------------------------------<br>
</p>
<p><font face="monospace">Vector registers<br>
<br>
It has been the long standing existing practice to treat
hardware<br>
vector registers as arrays of a fundamental base type. To
deliniate<br>
these hardware register arrays from arrays in the language
source they<br>
have been given the DW_AT_GNU_vector attribute. This proposal
simply<br>
standardizes the existing behavior.<br>
<br>
In Section 2.2 Attribute Types, DW_AT_vector and<br>
DW_AT_variable_vector_width shall be added to Table 2.2<br>
<br>
--------------------------------------------------------------------<br>
DW_AT_vector | A hardware vector register<br>
DW_AT_variable_vector_width | Array bound for hardware<br>
| implementation defined vector
register<br>
| width<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_vector and
the<br>
paragraph added to Section 5.13 below for<br>
DW_AT_variable_vector_width.<br>
<br>
In Section 2.5.1.2 Register values replace the description of<br>
DW_OP_regval_type with the following:<br>
<br>
--------------------------------------------------------------------<br>
The DW_OP_regval_type operation provides the contents of a
given<br>
register interpreted as a value of a given type. The first
operand<br>
is an unsigned LEB128 number, which identifies a register
whose<br>
contents is to be pushed onto the stack. The second operand
is an<br>
unsigned LEB128 number that represents the offset of a
debugging<br>
information entry in the current compilation unit, which
must be a<br>
DW_TAG_base_type entry that provides the type of the value<br>
contained in the specified register or it must be an<br>
DW_TAG_array_type with a DW_AT_vector attribute.<br>
<br>
[non-normative] A DW_TAG_array_type with a DW_AT_vector
attribute<br>
is the way that a vector register is specified and can be<br>
considered a base type for the architecture.<br>
--------------------------------------------------------------------<br>
<br>
In Section 2.5.1.3 Stack Operations replace the description of<br>
DW_OP_deref_type with the following:<br>
<br>
--------------------------------------------------------------------<br>
The DW_OP_deref_type operation behaves like the
DW_OP_deref_size<br>
operation: it pops the top stack entry and treats it as an<br>
address. The popped value must have an integral type. The
value<br>
retrieved from that address is pushed together with a type<br>
identifier. In the DW_OP_deref_type operation, the size in
bytes<br>
of the data retrieved from the dereferenced address is
specified<br>
by the first operand. This operand is a 1-byte unsigned
integral<br>
constant whose value which is the same as the size of the
type<br>
referenced by the second operand. The second operand is an<br>
unsigned LEB128 integer that represents the offset of a
debugging<br>
information entry in the current compilation unit that
provides<br>
the type of the data pushed. This entry must be either a<br>
DW_TAG_base_type entry or a DW_TAG_array_type entry with a<br>
DW_AT_vector attribute.<br>
--------------------------------------------------------------------<br>
<br>
Replace the description of DW_OP_xderef_type with the following:<br>
<br>
--------------------------------------------------------------------<br>
The DW_OP_xderef_type operation behaves like the
DW_OP_xderef_size<br>
operation: it pops the top two stack entries, treats them as
an<br>
address and an address space identifier, and pushes the
value<br>
retrieved. In the DW_OP_xderef_type operation, the size in
bytes<br>
of the data retrieved from the dereferenced address is
specified<br>
by the first operand. This operand is a 1-byte unsigned
integral<br>
constant whose value value is the same as the size of the
type<br>
referenced by the second operand. The second operand is an<br>
unsigned LEB128 integer that represents the offset of a
debugging<br>
information entry in the current compilation unit that
provides<br>
the type of the data pushed. This entry must be a
DW_TAG_base_type<br>
entry or a DW_TAG_array_type entry with a DW_AT_vector
attribute.<br>
--------------------------------------------------------------------<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 registers which mirror the<br>
language concept of an array.<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 hardware vector register,
shall be<br>
denoted with DW_AT_vector. The the width of the register
shall be<br>
specified as an array dimension and the type contained
within the<br>
register must be a DW_TAG_base_type entry.<br>
--------------------------------------------------------------------<br>
<br>
In Section 5.13 Subrange Type Entries insert the following
paragraph<br>
between the paragraph defining DW_AT_threads_scaled and the one<br>
defining DW_AT_lower_bound and DW_AT_upper_bound.<br>
<br>
--------------------------------------------------------------------<br>
The subrange entry may have a DW_AT_variable_vector_width<br>
attribute, which is a flag. If present, this attriburte
indicates<br>
that the width of a vector is defined by the hardware<br>
implementation of the target. The actual width of the vector<br>
registers can be determined at runtime but is unknown at
compile<br>
time.<br>
--------------------------------------------------------------------<br>
<br>
</font></p>
<p><br>
</p>
</body>
</html>