[Dwarf-discuss] ISSUE: vector types. V2

[Pedro Alves]

Hi!

On 2023-04-12 1:18 p.m., Jakub Jelinek wrote:
> On Wed, Apr 12, 2023 at 01:05:14PM +0100, Pedro Alves wrote:
>>> I thought Ben has posted the details.
>>> In memory they look the same as 0 based arrays, but they often have
>>> different calling conventions (argument passing, returning), they support
>>> various arithmetic operations on them, in C++ they support even comparisons
>>> (though, unlike scalar comparisons, vector comparisons produce element
>>> values 0 for false and -1/all ones for true), they don't promote to pointers.
>>> So, for the debug info consumers it is significantly different behavior than arrays.
>>> If a is int a[16];, then a + 2 is &a[0] + 2, while if a is int
>>> __attribute__((vector_size (16 * sizeof (int)))), a + 2 would be either an
>>> error if the language extension doesn't allow vector + scalar, or
>>> {a[0]+2,a[1]+2,a[2]+2,...,a[15]+2} vector.
>>
>> I think the open question is more like -- why only allow base types and vector types
>> in the expression stack, why not allow other types like regular arrays and structs?
>> Why do vector types need to be put on the stack, while arrays and structs don't?
>> What is special about vector types in that sense?
> 
> Mainly that in the base languages (with the corresponding extensions) basic
> arithmetics is possible on those types.  Then it is easy to describe a lot
> of those DW_OP_* operations in terms of that arithmetics.  DW_OP_plus adds
> two signed or unsigned integers or floats or vectors of 4 doubles the way
> that addition works on those types.  

Thanks!  We were discussing this in the DWARF for GPUs group, and I took the action
item of asking you some more details.  :-)

Do you have an actual example where we could end up with a DWARF expression like that,
involving vectors?  Maybe for a location expression defining an implicit (expression + stack_value)?
In the group, people generally agreed that it might be useful in light of what you explained, but we
were wary of adding it to the spec if it ends up never used in practice (say, because you always
end up describing the vector with a composite or a simple locdesc, with no arithmetic or such),
as it forces all consumers to implement vector operations (plus, etc.), and Ben was saying that
he tried to make GCC output DW_AT_GNU_vector in such a case, but somehow couldn't make it work.

#1 - if we don't allow putting vectors on the stack now, and then it turns out needed, allowing
     it ends up being a very simple DWARF extension that doesn't really affect anything (just remove
     the only-base-types restriction), so really nobody would wait for DWARF 7 to allow it,
     if they really needed it.

#2 - if we do allow putting vectors on the stack now, and then it turns out never needed, we
     risk making all consumers out there worry about implementing vector operations.

Option #1 seems safer, but if it's really needed, we should definitely allow it.  Having an
example to put in the proposal would be great.

> It is harder to describe what it means
> to add two structures, or arrays.  

Agreed for structures, but for arrays, it begs the question -- some languages, like Fortran,
do allow the same operations on arrays.  Like "A = B + C".  So how come the need for putting
arrays on the stack hasn't surfaced considering those languages?  Arrays vs vectors
don't appear different in this regard for such languages?

Pedro Alves

> While e.g. C++ has operator overloading,
> I think DWARF should describe what happens in such operations using the
> function calls or whatever they lower to, so the DWARF stack better should
> be limited only to intrinsic operations on the types.
> Furthermore, the former restriction for base types only (perhaps with small
> tweaks) is needed for producers to be able to actually produce the debug
> information.  The type DIEs in typed DWARF stack are referenced using
> uleb128 from the start of the CU, currently implementations can just make
> sure the base types (or perhaps in the future vector types) which are ever
> referenced by some typed DWARF stack are put first in the CU, as soon as
> you'd allow aggregates which in its various exprloc blocks could have typed
> DWARF stack themselves, sizing their uleb128 would be dependent on the
> placement of the type DIEs and that would depend on the resolution of the
> typed DWARF stack op sizes, circular dependencies with a nightmare to
> resolve (especially when we want to avoid non-canonical uleb128).
> 
> 	Jakub
>