On 4/6/23 03:16, Jakub Jelinek wrote:
On Wed, Apr 05, 2023 at 07:16:35PM -0700, Ben Woodard via Dwarf-discuss wrote:
To distinguish these vector types from regular C arrays, GCC's DWARF
describes a vector type as an array with the DW_AT_GNU_vector
attribute.  Clang also supports the GCC vector extensions, and
describes the vector types in DWARF using the same attribute as GCC.
Support for this DWARF extension has been implemented in GDB for well
over a decade.

Other languages have support for vector types, with similar ABI and/or
API implications, and so DW_AT_GNU_vector is also used for languages
beyond C/C++ today.

This proposal standardizes the existing behavior.
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.

Sounds fine to me. I will make that part of my V3 proposal. As I said before, I really didn't have much pushing me one way or another. On one hand we have: "just codifies existing practice" and the somewhat discredited "semantically the same as the existing array type" ...

But as you also mention, vector types are in various ways different from
array types.
... and on the other hand there are the ways that it have been pointed out such as: "C arrays decay into pointers" "always begin at zero" and "can be passed by value".
  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).

No on some modern GPUs you can have matrix types. e.g. https://gpuopen.com/learn/amd-lab-notes/amd-lab-notes-matrix-cores-readme/ and I believe Google's TPU. While I think I think this is still rare, the underlying way that it is built into at least some GPUs could be applied in other emerging architectures. They have a fixed sized register file and are just specifying how it is partitioned. Even though we are in one sense talking about an architectures registers, these intrinsic types can also exist in memory and be passed by values and all the other things that define the vector type.

We also have a bit of a problem with nomenclature. If we accept that these types can also be multi-dimensional as indicated the matrix types above, we probably shouldn't be using the "vector" terminology because by definition "vectors" are one dimensional arrays and DW_TAG_array is already taken. This kind of pushes me back toward using DW_TAG_array with an attribute.

When you consider the broader scope of all languages, I feel like C "arrays" are actually the odd one and I have already said that I personally believe that the "decay to pointer" behavior in C/C++ is the problem because of the ambiguity it creates when doing static analysis. When looking at the DWARF, I would like to know if a parameter is a pointer that is the head of linked list or if the programmer in the source language actually specified an array.

  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.

I kind of agree as well but I have not been able to convince Tony Tye of that and I respect his opinion on the matter. I've also looked at code that uses the current DW_AT_GNU_vector and I have not been able to find a case where any DWARF expression puts these vector types on the stack. I believe that this is at least partially because current consumers couldn't handle putting vectors on the stack. Just playing around with GCC, I was unable to figure out a way to provoke it to try. I was thinking that it might have something like putting a bunch of pointers into a a vector register then doing scatter gather.

You are probably the person who would know when when a vector type might need to be put on the stack.

-ben


        Jakub


--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Reply via email to