[Dwarf-discuss] ISSUE: CPU vector types.

[Ben Woodard]

In general I like this, I will steal / plagiarize ;-) and merge it to form a V2 Vector proposal and send it out.  

There are two things that I still am trying to settle in my mind. I can see both both ways and have yet to come up with fully convincing arguments either way.

One is: Should it be an attribute on a base type DW_AT_vector, or a type DW_TAG_vector. The two strongest arguments I have for the attribute vs the tag are:
1) this is current behavior, why change it?
2) It seems like a tag would be practically semantically identical to the current array. 
 
The second thing is: How important modifying the language in the DWARF operator section to allow the extraction of individual elements from the vector. Can DWARF expressions be constructed for both big endian and little endian architectures that allow the individual elements to be extracted as requested by the debuggers for these vector types when the location of the vector type could be in a register, or in memory. This is where I think that the people including you over at AMD and Intel who have been working on debugging vectorized code are better informed than I am. The DWARF stack and location descriptions does not come up as often when doing static analysis.

-ben

> On Apr 4, 2023, at 4:14 AM, Pedro Alves <pedro@palves.net> wrote:
> 
> On 2023-04-04 11:09 a.m., Pedro Alves wrote:
>>> On 2023-04-04 12:22 a.m., Kyle Huey wrote:
>>>> On Mon, Apr 3, 2023 at 12:42 PM Pedro Alves via Dwarf-discuss <dwarf-discuss@lists.dwarfstd.org <mailto:dwarf-discuss@lists.dwarfstd.org>> wrote:
>>> 
>>>    Hi Ben,
>>> 
>>>>    On 2023-03-24 6:19 p.m., Ben Woodard via Dwarf-discuss wrote:
>>> 
>>>> 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.
>>> 
>>>    In light of the recent discussion, I was thinking how it would help if the
>>>    proposal was laid out in terms of vector types instead of hardware registers.
>>> 
>>> 
>>> I think the proposed language here is a bit too C/C++ centric.
>> 
>> This is introducing the need for the attribute.  The audience is the committee, not DWARF spec readers,
>> because none of this text would end up in the spec.  It is just setting the ground.  It is true that other
>> languages have vector types as well, but I'd think that even if only C/C++ had them, that would
>> not be reason to not support the types.  But we can certainly tweak the language to cover other languages.
> 
> Here's what I would suggest.
> 
> ~~~~~~~~~
> Vector types
> 
> Some languages support vector data types, which are not possible to
> represent today in standard DWARF.  In very broad strokes, 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.
> 
> - You can pass vector types by value to functions, and likewise
>  functions can return vector types by value.  You can not do either
>  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.  Clang also supports the GCC vector extensions, and
> describes the vector types in DWARF using the same attribute as GCC.
> 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.
> 
> This proposal standardizes the existing behavior.
> ~~~~~~~~~
>