[Dwarf-discuss] EXTERNAL: Re: ISSUE: tensor types. V3

[Todd Allen]

I've been playing catch-up on this discussion today.  I was convinced of the
value early on just based on the need of this information to follow the ABI
parameter passing rules on certain architectures.  And I was with you right
up until this V3 version.  Comments below:

On Thu, Apr 13, 2023 at 11:57:08AM -0700, Dwarf Discussion wrote:
>    I didn't put back any changes that would allow these tensor types to
>    appear on the DWARF stack. I feel that particular topic hasn't been
>    settled yet. The general plan is I will work with Jakub and create some
>    cases where a compiler could want to put these vector types on the DWARF
>    stack. Tony Tye and the AMD team believe that the vector types do not need
>    to be on the stack and believe that all the cases where the debuggers
>    would want to access elements within the vector can be addressed with
>    offsetting. IIUC a key point seems to be that they have never seen a case
>    where an induction variable was embedded in a slot in a vector register,
>    it always is a scalar. (I am not sure that I fully grokked their argument
>    -- so please correct me) In the cases where it was, it could still be
>    accessed as an implicit. Once I've got some examples of how a debugger
>    might want to put vector types on the DWARF stack, the AMD team can
>    suggest alternative approaches. I said that I would make a V4 proposal if
>    the group ultimately comes to a consensus that vector registers are in
>    fact needed on the stack.

A proposal to allow vector types on the DWARF expression stack easily could be
a distinct proposal, although it obvious would have a dependency on this one.
This seems like a good application of the "keep proposals small" philosophy.

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

How do you envision debuggers using this information?  Merely disallowing things
like operator++, or disallowing casts, or certain flavors of casts?  (Those were
the differences I spotted in that table.)  This doesn't seem terribly
compelling.  But if others think it is, maybe this should be broken up into
distinct features instead of a lumpy enum?

-- 
Todd Allen
Concurrent Real-Time