<div dir="ltr"><div dir="ltr"><div>Various thoughts...</div><div><br></div><div>
<span class="gmail-im">> Not sure if supporting dimensions in the way which is done<br>
> for arrays is needed (I believe vector types are always one-dimensional<br>
> indexed from 0). <br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">"always"? There are many element by element operations on multidimensional arrays that might benefit</span></div><div><span class="gmail-im">from use of vector hardware. Why make that an orphaned option?<br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">> And we almost certainly want to allow vectors on DWARF expression stack; <br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">What is so special about vector types in this regard. What do you have against values of array or structure types being</span></div><div><span class="gmail-im">on the stack (the latter especially because they are often/mostly passed by value in many languages, even C)?<br></span></div><div><span class="gmail-im">I don't see the point of vector types being special.<br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">To broaden the discussion just a bit, it is appropriate to ask how DW_AT_vector interacts with other array attributes?</span></div><div><span class="gmail-im"></span></div><div><ul><li>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.<br></li><li>DW_AT_allocated and DW_AT_associated don't seem to make sense in combination with DW_AT_vector, perhaps? Or perhaps it does? <br></li><li>
DW_AT_data_location is even more interestingly unclear...</li></ul><div>Ron<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 6, 2023 at 7:03 AM Jakub Jelinek via Dwarf-discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org">dwarf-discuss@lists.dwarfstd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Apr 06, 2023 at 10:47:02AM +0000, Metzger, Markus T wrote:<br>
> >I don't think this is a good idea, we should go for<br>
> >DW_TAG_vector_type<br>
> >instead IMHO. DW_AT_GNU_vector used to be a good idea as an extension,<br>
> >as mentioned the (generic) vector types are in many ways similar to arrays,<br>
> >so even a DWARF consumer which doesn't understand DW_AT_GNU_vector could<br>
> >handle the vector types sanely in some cases.<br>
> >But as you also mention, vector types are in various ways different from<br>
> >array types. Not sure if supporting dimensions in the way which is done<br>
> >for arrays is needed (I believe vector types are always one-dimensional<br>
> >indexed from 0). And we almost certainly want to allow vectors on DWARF<br>
> >expression stack; I'd probably not make DW_TAG_vector_type a base type,<br>
> >but extended the typed DWARF stack so that it can contain base types or<br>
> >DW_TAG_vector_type of base types or something similar.<br>
> <br>
> Is there a limit to the length of such a vector type? Would the language<br>
<br>
GCC requires the vector types to have power of two element count and largest<br>
it supports is I think 0x40000000 elements. Of course, people rarely use<br>
such large vectors, using some orders of magnitude larger than what the hw<br>
can really support is a bad idea.<br>
<br>
In GCC, one uses vector_size attribute to define such types, so say<br>
typedef int V __attribute__((vector_size (64)));<br>
where 64 is number of bytes the vector has (so for 4 byte int it is 16<br>
elements).<br>
I think Clang supports both these vectors and also ext_vector_size<br>
attribute, where the latter specifies number of elements rather than size<br>
and I think has a little bit different other properties.<br>
On 64-bit ARM at least (unsure about RISCV), one can also have variable<br>
number element vectors, where the number of elements of the vector is<br>
determined by reading some hw register.<br>
<br>
> define fixed-length vectors as special built-in types or is the goal to support<br>
> arbitrary vector lengths?<br>
> <br>
> It might be good to maintain an upper limit on the size of a stack entry.<br>
<br>
I think it is better if consumers simply have some upper limit on their own,<br>
either hard limit, where for anything above that limit evaluation of the<br>
DWARF expression yields an optimized out state, or soft limit, where<br>
elements smaller than limit are encoded in DWARF stack directly (say as<br>
union of the various types known to fit under the limit) and for<br>
larger elements just encode them as reference to malloced data or something<br>
similar.<br>
<br>
Jakub<br>
<br>
-- <br>
Dwarf-discuss mailing list<br>
<a href="mailto:Dwarf-discuss@lists.dwarfstd.org" target="_blank">Dwarf-discuss@lists.dwarfstd.org</a><br>
<a href="https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss" rel="noreferrer" target="_blank">https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss</a><br>
</blockquote></div>