[Dwarf-discuss] ISSUE: tensor types. V3

[Todd Allen]

On 4/21/23 16:31, Ben Woodard via Dwarf-discuss wrote:
>>
>>>     Insert the following paragraph between the first paragraph of
>>>     normative text describing DW_TAG_array_type and the second 
>>> paragraph
>>>     dealing with multidimensional ordering.
>>>
>>> --------------------------------------------------------------------
>>>         An array type that refers to a vector or matrix type, shall be
>>>         denoted with DW_AT_tensor whose integer constant, will 
>>> specify the
>>>         kind of tensor it is. The default type of tensor shall be 
>>> the kind
>>>         used by the vector registers in the target architecture.
>>>
>>>             Table 5.4: Tensor attribute values
>>> ------------------------------------------------------------------
>>>         Name              | Meaning
>>> ------------------------------------------------------------------
>>>         DW_TENSOR_default | Default encoding and semantics used by 
>>> target
>>>                   | architecture's vector registers
>>>         DW_TENSOR_boolean | Boolean vectors map to vector mask 
>>> registers.
>>>         DW_TENSOR_opencl  | OpenCL vector encoding and semantics
>>>         DW_TENSOR_neon    | NEON vector encoding and semantics
>>>         DW_TENSOR_sve     | SVE vector encoding and semantics
>>> ------------------------------------------------------------------
>> As someone who was not sitting in on your debugging GPUs discussions, 
>> this table
>> is baffling.  Is it based on the "Vector Operations" table on the clang
>> LanguageExtensions page you mentioned?
> Yes
>> That page is a wall of text, so I might
>> have missed another table, but these values are a subset of columns 
>> from that
>> table.
>>
>> 1 of the values here is a source language (opencl), 2 reflect 
>> specific vector
>> registers of one specific architecture (neon & sve), and I don't even 
>> know what
>> boolean is meant to be.  Maybe a type that you would associate with 
>> predicate
>> registers?  I think this table needs a lot more explanation.
>
> This was something that Pedro pointed out and it was something that I
> hadn't thought of. The overall justification for this is that these
> types were semantically different than normal C arrays in several
> distinct ways. There is this table which explains the differences:
> https://clang.llvm.org/docs/LanguageExtensions.html#vector-operations
> The argument is that the semantics of different flavors are different
> enough that they need to be distinct.
>
> I really do not know much of anything about OpenCL style vectors, I
> wouldn't at all be against folding that constant in because it is
> something that could be inferred from the source language. I left it in
> because I thought that there might exist in cases where clang compiles
> some OpenCL code that references some intrinsics written in another
> language like C/C++ which depends on the semantics of OpenCL vector 
> types.
>
> NEON, yeah I think we should drop that one. The current GCC semantics
> are really Intel's vector semantics. By changing it from "GCC semantics"
> to "Default encoding and semantics used by target architecture's vector
> registers" I think we eliminate the need for that.
>
> You are correct boolean is for predicate register types. After looking
> at the calling conventions, these are not passed as types themselves. So
> for the purpose of this submission, I don't think we need it. I believe
> that some of the stuff that Tony and the AMD, and intel guys are almost
> ready to submit has DWARF examples of how to make use of predicate
> registers in SIMD and SIMT and access variables making use of predicate
> registers should be sufficient for those.
>
> ARM SVE and RISC-V RVV are really weird because of those HW
> implementation defined vs architecturally defined register and therefore
> type widths. It has been a couple of compiler generation iterations
> since I looked at the DWARF for those but but when I last looked, the
> compilers didn't know what to do with those and so they didn't generate
> usable DWARF. So I feel like there are additional unsolved problems with
> the SVE and RVV types that will need to be addressed. It is a problem,
> that I know that I need to look into -- but right now I do not have any
> "quality of DWARF" user issues pulling it closer to the top of my
> priority list. The only processor I've seen with SVE is the A64FX used
> in Fugaku and the HPE Apollo 80's, the Apple M1 and M2 don't have it and
> I haven't seen any of the newer ARM enterprise CPUs. I don't think there
> are any chips with RVV yet. Once more users have access to hardware that
> supports it, I know that it will be more of a problem. I kind of feel
> like that will be a whole submission in and of itself.
>
>
So you're thinking that "OpenCL vector semantics" ought to be 
determinable from DW_AT_language DW_LANG_OpenCL?  Seems reasonable.

DW_TENSOR_boolean: Could it just be determinable from the shape of the 
array?  For example:

<BOOL>  DW_TAG_base_type
            DW_AT_bit_size    : 1

         DW_TAG_array_type
            DW_AT_name        : predicate_t
            DW_AT_byte_size   : 16
            DW_AT_type        : <BOOL>
            DW_AT_tensor      : yes (encoding TBD)
                 DW_TAG_subrange_type
                 DW_AT_type        : <whatever>
                 DW_AT_lower_bound : 0
                 DW_AT_upper_bound : 128

NEON/SVE/RVV ought to be determinable by knowing what kind of machine 
the debugger is running on (ARM/RISC-V).  Or, for something like 
dwarfdump which might try to read a foreign-architecture ELF file, from 
the ELF header.  (Not that dwarfdump specifically is going to care...) 
As for NEON vs. SVE, is there a need to differentiate them?  And can it 
not be done by shape of the type?

If all those things are eliminated, then you're back to just needing a 
flag: tensor vs. not-tensor.

> How about:
>
>            Table 5.4: Tensor attribute values
> ------------------------------------------------------------------
>        Name              | Meaning
> ------------------------------------------------------------------
>        DW_TENSOR_default | Default encoding and semantics used by target
>                          | architecture's vector registers
> ------------------------------------------------------------------
>
> The point is I believe that there are going to be flavors. Can we leave
> it an enum?
>
> Then if SVE, and RVV end up being sufficiently different we have a way
> to handle them. I also double checked and ARM V9.1 SME is now publicly
> disclosed so we have at least 3 architectures that I know that have
> matrix registers but the compiler support hasn't quite caught up yet.
>
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.

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.

Regards,
Todd