[Dwarf-discuss] ISSUE: vector types. V2

[Ron Brender]

Various thoughts...

> 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).

"always"? There are many element by element operations on multidimensional
arrays that might benefit
from use of vector hardware. Why make that an orphaned option?

> And we almost certainly want to allow vectors on DWARF expression stack;

What is so special about vector types in this regard. What do you have
against values of array or structure types being
on the stack (the latter especially because they are often/mostly passed by
value in many languages, even C)?
I don't see the point of vector types being special.

To broaden the discussion just a bit, it is appropriate to ask how
DW_AT_vector interacts with other array attributes?

   - DW_AT_{bit|byte}_stride makes no sense when a vector object is in a
   vector register. Is such a combination invalid or does it reasonably imply
   scatter/gather when such an object is copied from/to a vector register? If
   so, we should say so.
   - DW_AT_allocated and DW_AT_associated don't seem to make sense in
   combination with DW_AT_vector, perhaps? Or perhaps it does?
   - DW_AT_data_location is even more interestingly unclear...

Ron

On Thu, Apr 6, 2023 at 7:03 AM Jakub Jelinek via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> 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
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20230406/22631f91/attachment.htm>