[Dwarf-discuss] ISSUE: vector types. V2

[Jakub Jelinek]

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.  It is harder to describe what it means
to add two structures, or arrays.  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