[Dwarf-discuss] ISSUE: vector types. V2

[Jakub Jelinek]

On Thu, Apr 06, 2023 at 10:47:02AM +0000, Metzger, Markus T wrote:
> >I don't think this is a good idea, we should go for
> >DW_TAG_vector_type
> >instead IMHO.  DW_AT_GNU_vector used to be a good idea as an extension,
> >as mentioned the (generic) vector types are in many ways similar to arrays,
> >so even a DWARF consumer which doesn't understand DW_AT_GNU_vector could
> >handle the vector types sanely in some cases.
> >But as you also mention, vector types are in various ways different from
> >array types.  Not sure if supporting dimensions in the way which is done
> >for arrays is needed (I believe vector types are always one-dimensional
> >indexed from 0).  And we almost certainly want to allow vectors on DWARF
> >expression stack; I'd probably not make DW_TAG_vector_type a base type,
> >but extended the typed DWARF stack so that it can contain base types or
> >DW_TAG_vector_type of base types or something similar.
> 
> Is there a limit to the length of such a vector type?  Would the language

GCC requires the vector types to have power of two element count and largest
it supports is I think 0x40000000 elements.  Of course, people rarely use
such large vectors, using some orders of magnitude larger than what the hw
can really support is a bad idea.

In GCC, one uses vector_size attribute to define such types, so say
typedef int V __attribute__((vector_size (64)));
where 64 is number of bytes the vector has (so for 4 byte int it is 16
elements).
I think Clang supports both these vectors and also ext_vector_size
attribute, where the latter specifies number of elements rather than size
and I think has a little bit different other properties.
On 64-bit ARM at least (unsure about RISCV), one can also have variable
number element vectors, where the number of elements of the vector is
determined by reading some hw register.

> define fixed-length vectors as special built-in types or is the goal to support
> arbitrary vector lengths?
> 
> It might be good to maintain an upper limit on the size of a stack entry.

I think it is better if consumers simply have some upper limit on their own,
either hard limit, where for anything above that limit evaluation of the
DWARF expression yields an optimized out state, or soft limit, where
elements smaller than limit are encoded in DWARF stack directly (say as
union of the various types known to fit under the limit) and for
larger elements just encode them as reference to malloced data or something
similar.

	Jakub