[Dwarf-discuss] ISSUE: tensor types. V3

[Todd Allen]

On 4/24/23 13:27, Ben Woodard via Dwarf-discuss wrote:
>
>> As for NEON vs. SVE, is there a need to differentiate them?  And can it
>> not be done by shape of the type?
>
> That one continues to be hard. ARM processors that support SVE also have
> NEON registers which like the Intel SSE MMX AVX kind of vector registers
> are architecturally specified as having a specific number of bits.
> Handling those are trivial.
>
> The weird thing about SVE registers (and the same things also apply to
> RVV) are that the number of bits is not architecturally defined and is
> therefore unknown at compile time. The size of the registers can even
> vary from hardware implementation to hardware implementation. So a
> simple processor may only have a 128b wide SVE register while a monster
> performance core may have 2048b wide SVE registers. The predicate
> registers scale the same way. I that it can even vary from core to core
> within a CPU sort of like intel's P-cores vs E-cores. To be able to even
> know how much a loop is vectorized you need to read a core specific
> register that specifies how wide the vector registers are on this
> particular core. Things like induction variables are incremented by the
> constant in that core specific register divided by size of the type
> being acted upon. So some of the techniques used to select lanes in
> DWARF don't quite work the same way.
>
> Just to make things even more difficult, when one of these registers are
> spilled to memory like the stack the size is unknown at compile time and
> so any subsequent spilling has to determine the size that it takes up.
> So any subsequent offsets need to use DWARF expressions to that
> reference the width of the vector.
>
> ...and then there is SME which is like SVE but they are matrices rather
> than vectors. The mind boggles.
>
So the variability of the vector size is the only significant difference 
that you've identified?  If so, then I think the shape of the array type 
probably is sufficient.  For SVE, the DW_TAG_subrange_type will have a 
DW_AT_upper_bound which is a variable (reference or dwarf expr), or the 
DW_TAG_array_type's DW_AT_{byte,bit}_size will be a variable, or both.  
Meanwhile, NEON would use DW_AT_bit_size 128 (or DW_AT_byte_size 16) and 
a constant DW_AT_upper_bound (128/bitsizeof(elementtype)).  That seems 
like it very directly reflects the difference between the two vector types.

>> If all those things You argued that it still should be an enum, but 
>> with only one "default"
>> value defined.  And I guess any other values that might be added later
>> would be (or at least start as) vendor extensions. It's peculiar, and I
>> don't think we have that anywhere else in the standard.
> I guess that my point is that I'm fairly certain that SVE and RVV will
> need special handling and when the compilers start handling the matrix
> types that the hardware is starting to support, they are going need some
> help as well.
If there's something more peculiar about the types inhabiting these 
vector registers than "variable size", that might convince me.  But 
merely being variable-sized doesn't.
>> If it ever became necessary, you can always add a 2nd attribute for it.
>> As an example, in our Ada compiler decades ago, we did this for
>> DW_AT_artificial.  It's just a flag, so either present or not-present.
>> We added a 2nd DW_AT_artificial_kind with a whole bunch of different
>> enums for the various kinds our compiler generated.  The point is you
>> still can get there even if DW_AT_tensor is just a flag.
>
> Totally, not opposed to that if that is the way that people want to
> handle it. My only (admittedly weak) argument against doing it that way
> is that there there will now be two attributes rather than one and the
> space that it takes up. John DelSignore was just dealing with a program
> that had 4.9GB of DWARF, it would be nice to keep it as compact as
> possible. Of course most of that is likely location lists and template
> instantiations and stuff like that not the relatively rare case like
> this. The cases where this shows up are likely going to be fairly rare.
>
> Would this be an acceptable compromise for V4 of my proposal? I drop it
> back to just being a flag for the time being. Then in a subsequent
> submission (which may or may not be in the DWARF6 cycle -- but hopefully
> is in time for DWARF6), if I find it necessary to make a flavor to
> support SVE, RVV or SME, then my submission for that will include
> changing DW_AT_tensor to requiring a constant that then references an
> enum like I did above. If it comes out before DWARF6 is released then
> great, we don't have to redefine anything. If It bumped to DWARF7 then
> we add a _kind attribute.

You can submit it in whichever form you prefer.  I supposed you were 
soliciting comments here to get it in a form as close to acceptable as 
possible before submitting it.  After you do, the committee will discuss 
it, probably ad nauseum.  (And I'll be no exception.)  And changes may 
happen then.  Seldom is it rubber stamp vs. reject.

Regards,
Todd