[Dwarf-discuss] ISSUE: CPU vector types.

[Kyle Huey]

On Mon, Mar 27, 2023 at 11:52 PM Cary Coutant via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> > Vector registers
> >
> > It has been the long standing existing practice to treat hardware
> > vector registers as arrays of a fundamental base type. To deliniate
> > these hardware register arrays from arrays in the language source they
> > have been given the DW_AT_GNU_vector attribute. This proposal simply
> > standardizes the existing behavior.
> >
> > In Section 2.2 Attribute Types, DW_AT_vector and
> > DW_AT_variable_vector_width shall be added to Table 2.2
> >
> >     --------------------------------------------------------------------
> >     DW_AT_vector                | A hardware vector register
> >     DW_AT_variable_vector_width | Array bound for hardware
> >                                 | implementation defined vector register
> >                                 | width
> >     --------------------------------------------------------------------
>
> I don't understand what tags this DW_AT_vector attribute would apply
> to. Vector registers aren't *types*, they're *locations*, so it
> doesn't really make sense to me to put this attribute on a
> DW_TAG_array_type. We don't have DW_TAGs that describe registers; the
> ABI defines the registers and DWARF producers and consumers should
> understand and agree on the sizes and shapes of the various registers.
>
> In Tony's proposal, the new attribute modifies a base type, thus
> introducing a vector type, which might get placed in a vector
> register. But there, I don't see how the vector base type is
> fundamentally different from an array type. It seems it's just a dodge
> to make it a base type so that we can put whole vectors on the stack.
>
> Maybe what we're looking for is a DW_TAG_vector_type, whose DW_AT_type
> attribute gives the base type for each element of the vector. This
> seems to be more DWARF-like, and if we decide there's a reason to
> allow stack entries with vector types, we can do that.
>
> -cary
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss


(Caveat this is all amd64 specific, I haven't looked at ARM.)

Last I looked into this I concluded that DW_AT_GNU_vector is a big hack to
make debuggers capable of handling function entries and exits that involve
the intrinsic types that hardware vendors have added for their SIMD
features.

In the SYSV AMD64 ABI (download link
https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build)
in Section 3.2.3 there is a subsection "Classification". Immediately after
the base types, _m64/_m128/_m256/_m512 are special cased to be part of the
"SSE" class. If you follow the algorithm described you'll note that
non-special cased arrays are treated as aggregates of the element type and
are not "promoted" to the "SSE" class. So _m256d and double[4], despite
having identical layouts in memory, will be classified as SSE/SSEUP and
MEMORY respectively by that algorithm (in particular note footnote 15
here). This is also easily verifable by compiling a trivial function that
takes _m256d and double[4] parameters.

A debugger usually doesn't care about any of this because the DIEs for
local/global variables will contain location information specifying where
to get the bytes from to render the variable. DWARF does not, however,
specify the locations of function return values at exit or parameters at
function entry[0]. These locations are needed, in turn, to display the
function return value upon function exit (think `ret` in gdb)[1] and to
invoke a function with user supplied parameters (think `call` in gdb).
Debuggers generally infer these locations from their knowledge of the
platform ABI[2]. The DW_AT_GNU_vector attribute informs the debugger that
these types are among the ones special-cased in the ABI and prevents the
need to do something even more unprincipled such as name matching.

DW_AT[_GNU]_vector is best understood not as "a hardware vector register"
but rather as a marker that "this type is eligible to be passed in hardware
vector registers at function boundaries according to the platform ABI".

- Kyle

[0] DWARF has DW_TAG_formal_parameter and those can contain location
information *but* DWARF does not specify that the location information must
be valid at function entry. For debug builds, compilers often emit
locations that are only valid after the function prologue has completed.
Post-prologue locations are useless for invoking the function in a debugger.
[1] Inferring the function return value location causes issues in other
contexts and I have a DWARF issue on that (221105.1)
[2] See e.g. amd64_classify in gdb/amd64-tdep.c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20230328/0ce9eebb/attachment.htm>