On Tue, Mar 28, 2023 at 1:17 PM David Blaikie wrote:
> > 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".
>
> My 2c wo
Thank you Kyle,
On 3/28/23 12:49, Kyle Huey wrote:
[1] Inferring the function return value location causes issues in
other contexts and I have a DWARF issue on that (221105.1)
Let me publicly state my support for your proposal for how to specify
the return value of a function.
I'm not sure
> 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".
My 2c would not be to describe these in terms of
hardware/implementa
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 regis
On 3/27/23 23:51, Cary Coutant 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_vecto
I've added this as DWARF Issue 230324.1. I'll report back after the
committee has reviewed it.
Thank you for your contribution!
-cary
On Fri, Mar 24, 2023 at 1:21 PM Linder, Scott via Dwarf-discuss
wrote:
>
> [AMD Official Use Only - General]
>
> Background
> ==
>
> The vendor extension
