Re: [Dwarf-discuss] Enhancement: DWARF Extension Registry

[Ben Woodard via Dwarf-discuss]

 only


It might have been a good one, it might have been a bad one; I don't 
know I wasn't involved. Maybe someone even did a prototype 
implementation that never was accepted into a mainline release. I think 
it is still worthwhile to allow an eager compiler developer to register 
those attributes do their prototype implementation in their own reserved 
sandbox. If it catches on, then great; they can provide more information 
so other tools can implement it. If the idea gets abandoned then the 
encodings only exist for that release of the DWARF version and the 
encodings can be reused in the next DWARF cycle.




That is enough for now,
Ron







On Fri, Nov 10, 2023 at 4:52 PM Ben Woodard via Dwarf-discuss 
 wrote:


DWARF Extension Registry


  Background

The DWARF standard has always had the wisdom to acknowledge the
need for Vendor Extensibility. Section 1.3.13 describes this
policy. For the producers it explicitly reserves some of the valid
values for encoding various constructs and promises not to use
those values in future versions of the standard. Consumers are
given the freedom and expected to skip over data that they do not
recognize.

The original intent of these vendor extensions was that they would
be a private agreement between a particular producer and a
cooperating consumer. However, the range of tools expanded beyond
a toolchain provided by a single vendor and so the concept of a
private agreement between a specific producer and a cooperating
consumer came to be regarded as a registry of vendor extensions
that every tool must be aware of for the sake of compatibility.

Because compatibility between tools was prioritized, the
extensions in these de facto registries were effectively
considered permanent unofficial DWARF encodings. This presumptive
permanence is in spite of the fact that in some cases:

 *

Producers that made use of these extensions were never
implemented or publicly released.

 *

Producers that made use of these extensions are so obsolete
that not only does the tool chain no longer exist but the
hardware that this toolchain was designed for no longer exists
except as historical artifacts.

 *

Official versions of DWARF encodings that accomplish the same
thing have been added to the standard making the vendor
extension obsolete.


The accumulation of these vendor extensions over the years has led
to problems with some DWARF constructs where they are running out
of available encodings that do not overlap with the ones used by
or reserved by the standard. In particular the range of vendor
vendor extension encoding is running particularly short in the
range of DW_OP encoding. This has led to several informal
proposals within the vendor community along the lines of an
official proposal 230324.1 Expression Operation Vendor
Extensibility Opcode https://dwarfstd.org/issues/230324.1.html
<https://dwarfstd.org/issues/230324.1.html>The basic idea in most
of these proposals is to extend the range of available vendor
extension encodings. While DWARF expression operations, Section
2.5, has the most extreme shortage of vendor encodings, other
DWARF constructs are also running out of usable encodings.


  Overview

This proposal is an alternative to 230324.1 and similar informal
approaches to increase the available encoding space. It does this
in two ways.

First it makes it explicit that Vendor Extensions can only be
interpreted in the context of a particular producer and a DWARF
standard version. This way obsolete vendor extensions can be
retired when a new version of the standard is released. It also
begins the process of replacing the expectation for consumers that
they can simply ignore encodings that they do not understand with
the expectation they will need to have producer and version
awareness when interpreting encodings. This is because tools
chains are no longer developed by a close knit group of developers
who all work for a single vendor. Tools are now developed by
diverse distributed teams and users need and rightly expect
interoperability.

Because the bulk of tool development is no longer done by vendors
who build a vertically integrated tool chain but rather is done by
looser confederation of projects that need to cooperate to achieve
compatibility, the term “vendor” is replaced with more generic
terms when referring to these extensions.

The second big change is it seeks to foster compatibility and
collaboration by taking the collection of informal registries such
as https://sourceware.org/elfutils/DwarfExtensions
<https://sourceware.org/elfutils/DwarfExtensions>and
https://llvm.org/docs/SourceLevelDebugging.html#new-dwarf-tags
&

Re: [Dwarf-discuss] Question: ETA?

[Ben Woodard via Dwarf-discuss]

I’ve asked this question personally many times directly to members of the executive committee. The overall answer seems to be “when we are done”. The thing is, there are quite a few proposals sitting in the DWARF issue queue that have yet to be discussed AT ALL in the official DWARF committee meeting and the current meeting is only one hour every other week. Plus, there are a rather large number of additional proposals which are quite extensive which are still being discussed outside of the DWARF committee meeting and haven’t yet made it to the DWARF issue queue. E.g. https://github.com/ccoutant/dwarf-locations  which is the standardization effort for https://www.llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html  I also have 3 more that I’m incubating which haven’t seen the light of day yet because of some of this other work. Anyway, before the change in administration, it seemed like we were rushing to get DWARF6 out the door with just minor corrections and revisions. Now, it seems like DWARF6 is going to have many more significant changes in it and it is going to take a while. Personally, I’m quite glad for this because I feel as though a lot more work needs to be done. Before the change in administration, I felt DWARF6 was being rushed. I would say check in again in 6 months and see where we are then.In the mean time, there is a https://snapshots.sourceware.org/dwarfstd/dwarf-spec/ which is the current working draft and keep an eye on the Issue queue.-benOn Nov 12, 2023, at 1:49 AM, Eleanor Bartle via Dwarf-discuss  wrote:Is there any plan for a time to release version 6? If not a time, then a condition? Say "2025" or "some time in the next year" or "when no new proposals are accepted for three months" or "when two independent implementations are fully compliant".-- Dwarf-discuss mailing listDwarf-discuss@lists.dwarfstd.orghttps://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

[Dwarf-discuss] Enhancement: DWARF Extension Registry

[Ben Woodard via Dwarf-discuss]

DWARF Extension Registry


 Background

The DWARF standard has always had the wisdom to acknowledge the need for 
Vendor Extensibility. Section 1.3.13 describes this policy. For the 
producers it explicitly reserves some of the valid values for encoding 
various constructs and promises not to use those values in future 
versions of the standard. Consumers are given the freedom and expected 
to skip over data that they do not recognize.


The original intent of these vendor extensions was that they would be a 
private agreement between a particular producer and a cooperating 
consumer. However, the range of tools expanded beyond a toolchain 
provided by a single vendor and so the concept of a private agreement 
between a specific producer and a cooperating consumer came to be 
regarded as a registry of vendor extensions that every tool must be 
aware of for the sake of compatibility.


Because compatibility between tools was prioritized, the extensions in 
these de facto registries were effectively considered permanent 
unofficial DWARF encodings. This presumptive permanence is in spite of 
the fact that in some cases:


 *

   Producers that made use of these extensions were never implemented
   or publicly released.

 *

   Producers that made use of these extensions are so obsolete that not
   only does the tool chain no longer exist but the hardware that this
   toolchain was designed for no longer exists except as historical
   artifacts.

 *

   Official versions of DWARF encodings that accomplish the same thing
   have been added to the standard making the vendor extension obsolete.


The accumulation of these vendor extensions over the years has led to 
problems with some DWARF constructs where they are running out of 
available encodings that do not overlap with the ones used by or 
reserved by the standard. In particular the range of vendor vendor 
extension encoding is running particularly short in the range of DW_OP 
encoding. This has led to several informal proposals within the vendor 
community along the lines of an official proposal 230324.1 Expression 
Operation Vendor Extensibility Opcode 
https://dwarfstd.org/issues/230324.1.html 
The basic idea in most of 
these proposals is to extend the range of available vendor extension 
encodings. While DWARF expression operations, Section 2.5, has the most 
extreme shortage of vendor encodings, other DWARF constructs are also 
running out of usable encodings.



 Overview

This proposal is an alternative to 230324.1 and similar informal 
approaches to increase the available encoding space. It does this in two 
ways.


First it makes it explicit that Vendor Extensions can only be 
interpreted in the context of a particular producer and a DWARF standard 
version. This way obsolete vendor extensions can be retired when a new 
version of the standard is released. It also begins the process of 
replacing the expectation for consumers that they can simply ignore 
encodings that they do not understand with the expectation they will 
need to have producer and version awareness when interpreting encodings. 
This is because tools chains are no longer developed by a close knit 
group of developers who all work for a single vendor. Tools are now 
developed by diverse distributed teams and users need and rightly expect 
interoperability.


Because the bulk of tool development is no longer done by vendors who 
build a vertically integrated tool chain but rather is done by looser 
confederation of projects that need to cooperate to achieve 
compatibility, the term “vendor” is replaced with more generic terms 
when referring to these extensions.


The second big change is it seeks to foster compatibility and 
collaboration by taking the collection of informal registries such as 
https://sourceware.org/elfutils/DwarfExtensions 
and 
https://llvm.org/docs/SourceLevelDebugging.html#new-dwarf-tags 
and 
collects them and brings them under the aegis of the DWARF standards 
body. To facilitate innovation and quickly meet producer’s and 
consumer’s needs the expectation is that registering a new producer 
specific construct and encoding would be a simple, light weight or even 
partially automated task. It would not be at all like amending the 
standard. The registry would be published on the DWARF standard’s web 
site so that consumers can easily find it. Each extension would be 
listed along with the producers that emit it and the range of DWARF 
standard versions that it applies to. When new DWARF standard versions 
are released, each extension will be reconsidered to see if it continues 
to add utility in the context of the new version of the DWARF standard. 
Extensions that persist over several versions of the DWARF standard 
probably should be considered for inclusion into the official standard.



 Proposed 

[Dwarf-discuss] Link to current working DWARF6 standard

[Ben Woodard via Dwarf-discuss]

Can we please add a link to the current evolving DWARF6 standard working draft 
somewhere on https://dwarfstd.org/index.html 

I was wanting to show someone that we have the current working copy that we 
produce and I was sure that you could navigate to it from the main page but I 
was unable to find it that way. If it is there (and I couldn’t find it) could 
we make it obvious?

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

[Dwarf-discuss] performance tools and inverted location lists

[Ben Woodard via Dwarf-discuss]

I was looking at 2 level location tables 
https://dwarfstd.org/issues/140906.1.html and can see how it could 
improve things there. One thing that I noticed about it was that it was 
based on some prior art done in HP-UX.


A nut that I have been trying to crack for a few years but haven't 
really figured out comes from the performance tools, binary analysis 
people and I could even make use of it for my ABI work. They would 
really like something that I've been calling "inverted location lists". 
Location lists are basically a function (yes I know it is technically a 
relation but let's not quibble about that right now):


   f( PC, "variable") -> location description

This totally makes sense in the context of a debugger where the context 
of the lookup includes the PC, and the user inputs the symbolic name of 
the variable. The point that I try to make is DWARF is not just for 
debuggers anymore. A much broader range of consumers is emerging.


In the context of performance tools, they need:

   f( PC,  location) -> symbolic name

The reason why I specify "concrete" location is because it is never 
going to be a literal constant or an implicit or a DWARF expression or 
any of the other things along those lines. It is going to be an address 
or a register, things that have concrete existence.


Here are the use cases for this that have come up:

 * For performance tools, they have some piece of code which is not
   performing as it should. The tools show them that they are getting a
   large number of cache misses between this PC and another PC. They
   can disassemble the machine code and they see a handful of
   instructions. To be able to figure out what is wrong they need to
   associate the operands of these instructions to what they refer to
   at the source level. Doing this disassembled optimized machine code
   and then associating the data accesses within it back to constructs
   within the source language really puts this level of analysis is the
   domain of experts and must be done by hand. Because of the limited
   information currently provided by DWARF it is not something that can
   be coded into a tool.
 * Within ABI analysis there are a few cases where compilation options
   can change the calling convention of a function sufficiently enough
   that it can create an ABI mismatch. The simple example that
   illustrates the point is SSE. You can pass vector operands by value
   in vector registers. However, if you compile a program without SSE
   then it is passed by reference. So in the ABI testing program, if I
   take the locations of the formal parameters at the call site and
   then use an inverted location list to look up what variables exist
   at those locations in the called function, if they don't match then
   I have an ABI problem.
 * One binary analysis use case is quite similar to the ABI use case,
   they see a call instruction, they can look up the target of the call
   to find the function prototype. From that they can figure out where
   the parameters to the function call are at the time of the call.
   However, they want to know in the calling scope what symbolic name
   in the source language for the parameter in a particular location at
   the time of the call. Simple example: find all the examples of
   "dlopen" calls - what library name is being opened, is it something
   that we can determine from static analysis or is it something read
   from a config file...

What all three of us have tried doing with limited success is taking the 
location list data and then inverting the mappings. The problem is that 
this is far from complete and generating that data is very 
computationally expensive.


I've looked for prior art to see if someone had come up with a solution 
to this but I haven't found any. The allusion to the HP-UX two level 
line maps is something that I had never come across before. Since the 
combined experience of this group is much deeper than what I have, does 
anybody know of any prior art that I can use as a basis for a DWARF 
feature enhancement issue?


-ben

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

Re: [Dwarf-discuss] ISSUE: tensor types. V4

[Ben Woodard via Dwarf-discuss]

This is my long overdue revision my vector types proposal. The main 
difference is Todd Allen and Markus Metzger together convinced me that 
adding flavors to the tensor attributes were not needed. It should 
replace the current proposal https://dwarfstd.org/issues/230413.1.html


Tensor types

Some compilers support vector data types, which are not possible to
represent today in standard DWARF.  A vector is an array of values.
These can be allocated to a SIMD vector register, if available, either
permanently or temporarily, and operations on vectors make use of SIMD
instructions, again if available.

For example, as an extension to C and C++, GCC supports defining
vector data types as described here:

  https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

In this C/C++ extension, vector types are similar to arrays, and you
can index and initialize them similarly, but they have some important
differences.  For example:

- C arrays automatically decay to pointers.  Vector types do not.

- Vector types can be passed by value to functions, and likewise
  functions can return vector types by value. Neither of which can be
  done with C arrays.

- Vector types can be used with a subset of normal C operations: +, -,
  *, /, unary minus, ^, |, &, ~, %.  For example, addition is defined as
  the addition of the corresponding elements of the operands.

A debugger that supports C/C++ expression evaluation will want to be
able to support these vector operations on vector objects too.

Vector types appear on function prototypes, so they have their own
mangling scheme in the Itanium ABI.

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.

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.

Support for this DWARF extension has been implemented in GDB for well
over a decade.

Other vendor's compilers have similar C/C++ extensions.  For example,
Motorola’s Altivec C/C++ Language Extensions, which predates GCC's
extensions.

Clang also supports the GCC vector extensions, and in some cases
describes the vector types in DWARF using the same attribute as
GCC. However, clang also supports many other types of vectors with
somewhat different semantics than those used by GCC.

https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors

In the process of refining this proposal, we debated whether this
proposal should be a tag like DW_TAG_vector or if it should be an
attribute applied to an array. It was clang's various flavors of
vectors with different semantics which ultimately led to the current
proposal where it is an atribute. While the different flavors of
vectors that clang supports are not sufficiently different to require
an argument defining different flavors a flag attribute can easily be
extended to accept a constant class if the need should ever arise.

It should be noted that one of the more challenging types of vector
for DWARF to deal with are variable vector lengths which are
implementation specific on a per core basis rather than specified in
the target architecture. It was thought that this may require a new
flavor of vector type. However, in at least one case ARM's SVE, these
challenges were addressed by moving the complexity out of DWARF and
providing a pseudo register in the runtime environment that specifies
the length of the vector.

https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst#dwarf-register-names

During the course of the discussion, it was pointed out that while no
compiler currently supports matrix types, there are several current
processors which have matrix registers that have intrinsics that allow
a programmer to access them. One example is AMD's second generation
CDNA processors and later.

https://gpuopen.com/learn/amd-lab-notes/amd-lab-notes-matrix-cores-readme/

Rather than introducing a second new attribute like DW_AT_matrix, we
thought that calling the attribute DW_AT_tensor was correct and
general enough to embrace the concept.

-

In Section 2.2 Attribute Types, DW_AT_tensor shall be added to Table 2.2


    DW_AT_tensor    | A language tensor type


The hyperlink in the "Identifies or Specifies" column shall point to
the paragraph added to Section 5.5 below for DW_AT_tensor.

In Section 5.5 Array Type Entries, replace first paragraph of
non-normative text with:


    [non-normative] Many languages share the concept of an “array,”
    which is a table of components of identical type. Furthermore,
    many architectures contain vector types which mirror the language
    concept of a 

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

[Ben Woodard via Dwarf-discuss]

On 4/24/23 13:17, Todd Allen via Dwarf-discuss wrote:

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.


I went back and revisited the research that I did on behalf of customers 
a few years back when customers first got access to SVE and started 
debugging it. The state of the art has advanced since I did that work.


Back then we ran into problems because the only way to get the size of 
the hardware vector was to read a core specific register. A big problem 
was that if you were debugging something like a core file, you didn't 
have access to the that core specific register. There was no way to 
reference the core specific register from DWARF.


Furthermore while on the systems that I was looking at, all the cores 
were the same, it was architecturally allowed to have different sizes of 
the vector registers depending on which core that you were running on.


At the time, we realized that there needed to be some "magic" that 
didn't exist at the time that provided the debugger with the width of 
the vector. It was this complexity that really left me feeling that SVE 
needed to be its own special thing.


At the time we discussed several options. One was pushing the size of 
the vector into a normal variable so that it could be referenced by 
DWARF; however we didn't know how to make that work because it could 
change depending on which core the code was executing on. There was also 
a kernel problem associated with that, the information about where the 
process was executing needed to be included in the crash dumps. There 
was also a feeling that there was something wrong with this approach 
because the only reason for the variable to exist would be to support 
debugging and keeping it up to date added overhead, and probably some 
kernel support.


Another idea we kicked around was giving the core specific register a 
name and number in the register file so that DWARF could access it. This 
broke ABI. At that time, that option was immediately shot down.


I wasn't able to give the customers a good answer. I didn't know how to 
solve the problem. Word evidently got back to ARM and they wrote: 
https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst#dwarf-register-names 
The big innovation that made this possible is ARM introduced a "pseudo 
register" which they call VG that is specified to exist in the execution 
environment. They even gave some examples how the DWARF should look for 
these types 
https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst#vector-types-beta 



I haven't looked at the implementation of how GCC implements the VG 
register yet. So I don't know how it handles 

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

[Ben Woodard via Dwarf-discuss]

On 4/24/23 09:50, Todd Allen via Dwarf-discuss wrote:

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:

  DW_TAG_base_type
             DW_AT_bit_size    : 1

      DW_TAG_array_type
             DW_AT_

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

[Ben Woodard via Dwarf-discuss]

On 4/21/23 12:56, Todd Allen via Dwarf-discuss wrote:

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.
Really -- that is what I care about too. Everything else that I have 
done was just to make it acceptable to everyone else.

  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?

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 

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

[Ben Woodard via Dwarf-discuss]

Here is V3 of what was my vector types proposal.

Changes since V2:

We discussed this extensively in the DWARF for GPUs meeting. Cary 
originally wanted it to be a TAG rather than an attribute on an array 
and quite frankly, I don't care and so my default position is "What Cary 
wants, Cary gets". However, Pedro pointed out LLVMs different flavors of 
vector types which like the vector types bubbled up from the target 
architecture to language source through intrinsics. Each of these 
different vectors flavors has slightly different semantics. There is a 
really nice table on 
https://clang.llvm.org/docs/LanguageExtensions.html#id15 that summarizes 
the differences. This changed the course of discussion and it seemed 
that the group moved back to making it an attribute on an array. Since 
there are multiple flavors of vector, this led to adding a parameter to 
the attribute that defines the flavor and a table which defines what 
those constants mean.


I brought up the point about matrix registers. Jakub is right there are 
currently no compilers which make use of matrix vector types right now. 
Even AMD's GPUs which do have intrinsics for matrix operations end up 
implementing them with arrays of vector registers. This area is rapidly 
evolving due to its heavy use in HPC and AI. The challenge appears to be 
the compilers haven't supported these operations yet. Cary came up with 
the idea of calling it a "tensor" rather than defining DW_AT_vector and 
then later adding DW_AT_matrix. So through the entire document, vector 
has been changed to tensor.


Markus pointed out a few problems in my V2 version, I tried to address 
those. They were pretty minor and obvious. Markus please verify that I 
did it to your satisfaction otherwise V4.


What has not changed since V2:

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.


As for DWARF consumers, according to Cary, the reason why DWARF 
operations are currently limited to base types is to make it relatively 
easy on the consumers. If vector registers are in fact needed on the 
stack, Zoran is fairly certain that changes that he's preparing to 
enable gdb to support GPUs would also automatically handle vector 
registers on the stack. The problem for gdb would be client server 
operation with gdbserver. The goal with gdbserver has been to keep its 
execution footprint very small. While having huge registers on the DWARF 
stack is reasonable when gdb is operating on the target or on the client 
side, on the server end it may pose a problem. John DelSignore said that 
TotalView has a similar concern because of its client server 
architecture. He did point out though that DWARF expressions are ephemeral.


My impression was that Cary wanted to add this tensor types issue to the 
DWARF issue queue for discussion and once question of vector registers 
on the stack is settled, this proposal can be amended or a new proposal 
addressing just that issue can be filed.



Tensor types

Some languages support vector data types, which are not possible to
represent today in standard DWARF.  A vector is an array of values.
These can be allocated to a SIMD vector register, if available, either
permanently or temporarily, and operations on vectors make use of SIMD
instructions, again if available.

For example, as an extension to C and C++, GCC supports defining
vector data types as described here:

https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

In this C/C++ extension, vector types are similar to arrays, and you
can index and initialize them similarly, but they have some important
differences.  For example:

- C arrays automatically decay to pointers.  Vector types do not.

- Vector types can be passed by value to functions, and likewise
  functions can return vector types by value. Neither of which can be
  done with C arrays.

- Vector types can be 

Re: [Dwarf-discuss] ISSUE: vector types. V2

[Ben Woodard via Dwarf-discuss]

I believe that all three points that you bring up here are correct and I 
will fix them in V3 of my proposal.



On 4/6/23 03:44, Metzger, Markus T wrote:

Hello Ben,



This is version 2 of my vector types submission.

Differences from V1:
- Made the submission about vector types rather than vector registers.
- Substituted Pedro's much better introduction for my own with minor edits.
- Removed the modifications to the DWARF Stack. The AMD people like
Pedro and Tony have been working on vector registers and vector types
for a long time and they do not know of a good reason why we need the
capability to a vector register on the DWARF stack. So I'm dropping that
part. Furthermore, I could not find any evidence in code that uses the
vector types that they needed to put vector types on the DWARF stack for
locations.
- Removed the variable vector length attribute. This was not existing
behavior. I'm fairly certain something like that is going to be
necessary but it doesn't need to be in this submission.



Vector types


Some languages support vector data types, which are not possible to
represent today in standard DWARF.  A vector is an array of values.
These can be allocated to a SIMD vector register, if available, either
permanently or temporarily, and operations on vectors make use of SIMD
instructions, again if available.

For example, as an extension to C and C++, GCC supports defining
vector data types as described here:

   https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

In this C/C++ extension, vector types are similar to arrays, and you
can index and initialize them similarly, but they have some important
differences.  For example:

- C arrays automatically decay to pointers.  Vector types do not.

- Vector types can be passed by value to functions, and likewise
   functions can return vector types by value. Neither of which can be
   done with C arrays.

- Vector types can be used with a subset of normal C operations: +, -,
   *, /, unary minus, ^, |, &, ~, %.  For example, addition is defined as
   the addition of the corresponding elements of the operands.

A debugger that supports C/C++ expression evaluation will want to be
able to support these vector operations on vector objects too.

Vector types appear on function prototypes, so they have their own
mangling scheme in the Itanium ABI.

Other vendors have similar C/C++ extensions.  For example, Motorola’s
Altivec C/C++ Language Extensions, which predates GCC's extensions.

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.

-

In Section 2.2 Attribute Types, DW_AT_vector and
DW_AT_variable_vector_width shall be added to Table 2.2


     DW_AT_vector    | A hardware vector type


Why hardware and not language?  I thought the proposal was changed
to model language vector types.


The hyperlink in the "Identifies or Specifies" column shall point to
the paragraph added to Section 5.5 below for DW_AT_vector.

In Section 5.5 Array Type Entries, replace first paragraph of
non-normative text with:


     [non-normative] Many languages share the concept of an “array,”
     which is a table of components of identical type. Furthermore,
     many architectures contain vector types which mirror the
     language concept of an array.


This isn't clear to me, but this is probably a consequence of defining
the attribute as hardware vector type.


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 type, shall be denoted with
     DW_AT_vector. The the width of the type shall be specified as an
     array dimension and the type contained within the register must be
     a DW_TAG_base_type entry.


This is still referring to a register.

Regards,
Markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, 

Re: [Dwarf-discuss] ISSUE: vector types. V2

[Ben Woodard via Dwarf-discuss]

On 4/6/23 03:47, Metzger, Markus T wrote:

Hello Jakub, Ben,


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.
But as you also mention, vector types are in various ways different from
array types.  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).  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.

Is there a limit to the length of such a vector type?


When it comes to CPUs and hardware vectors the architectural 
specification for aarch64 maxes out at 2048 bits (256 bytes). No current 
implementation that I am aware of goes beyond 512b though.


The RISC-V architecture RVV maxes out at 65536 bits (2^16 bits) which is 
8192 bytes.


I haven't done a survey of GPUs but in general they have HUGE register 
files in comparison to CPUs and this ends up meaning larger vectors or 
more vector registers or even matrix registers all of which can spill to 
memory or be loaded from memory. AIUI how these are organized into 
vectors or matrices is a tuning parameter in GPU design based upon the 
expected workload and how it interacts the memory subsystem.


When we are considering DWARF6 which will probably come out in 2024 and 
really start hitting tools in 2025 and will be around for a few years 
before DWARF7 even starts to be considered, I think we should anticipate 
hardware which will be available in the neighborhood of 2030. I wouldn't 
be surprised if there were steady growth in the size of hardware's 
register files between now and then. Furthermore, one of the things 
holding back development of the software backing AI running models and 
GPU based compute is programmer tooling (sorry, I am less familiar with 
graphics and game development) and DWARF is a big portion of that. So I 
think we need to design the standard to be a bit future proof in this area.



Would the language
define fixed-length vectors as special built-in types or is the goal to support
arbitrary vector lengths?


I understand your concern. A consumer needs to know how much memory are 
you going to going need to allocate for each entry on the DWARF stack.


if we allow these types on the DWARF stack, then I think that this is 
going to be something determined by the target architecture, and 
expressed through the Platform Specific ABI for the architecture which 
includes the calling conventions. So I would say that for a supported 
target language and architecture, a consumer will need to allocate 
sufficient storage for the DWARF stack entries to contain whatever size 
of entries that can be put on the stack. I believe that topic is beyond 
the scope of DWARF in and of itself. It is more the a question of: does 
a particular consumer support a particular language on a particular 
architecture.


Personally, I'm not sure if these vector and matrix types need to be put 
on the DWARF stack. On one hand, I have Jakub whose opinion I regard 
very highly who says that they will need to be on the stack. And on the 
other hand I have Tony whose opinion I also regard very highly who says 
that they do not need to be on the stack. I personally have not been 
able to settle the disagreement in my mind for myself.



It might be good to maintain an upper limit on the size of a stack entry.


Agreed -- but it isn't the 80's anymore. My development workstation has 
128GB of main memory and 16GB of VRAM. Even the massive 8kB needed for a 
full sized RISC-V RVV type is background noise and the maximum stack 
depth for any DWARF expression I've ever seen could still be counted on 
my hands. So I don't think things are likely to get too out of hand.


-ben




Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Ch

Re: [Dwarf-discuss] ISSUE: vector types. V2

[Ben Woodard via Dwarf-discuss]

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

[Dwarf-discuss] ISSUE: vector types. V2

[Ben Woodard via Dwarf-discuss]

This is version 2 of my vector types submission.

Differences from V1:
- Made the submission about vector types rather than vector registers.
- Substituted Pedro's much better introduction for my own with minor edits.
- Removed the modifications to the DWARF Stack. The AMD people like 
Pedro and Tony have been working on vector registers and vector types 
for a long time and they do not know of a good reason why we need the 
capability to a vector register on the DWARF stack. So I'm dropping that 
part. Furthermore, I could not find any evidence in code that uses the 
vector types that they needed to put vector types on the DWARF stack for 
locations.
- Removed the variable vector length attribute. This was not existing 
behavior. I'm fairly certain something like that is going to be 
necessary but it doesn't need to be in this submission.




Vector types


Some languages support vector data types, which are not possible to
represent today in standard DWARF.  A vector is an array of values.
These can be allocated to a SIMD vector register, if available, either
permanently or temporarily, and operations on vectors make use of SIMD
instructions, again if available.

For example, as an extension to C and C++, GCC supports defining
vector data types as described here:

  https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

In this C/C++ extension, vector types are similar to arrays, and you
can index and initialize them similarly, but they have some important
differences.  For example:

- C arrays automatically decay to pointers.  Vector types do not.

- Vector types can be passed by value to functions, and likewise
  functions can return vector types by value. Neither of which can be
  done with C arrays.

- Vector types can be used with a subset of normal C operations: +, -,
  *, /, unary minus, ^, |, &, ~, %.  For example, addition is defined as
  the addition of the corresponding elements of the operands.

A debugger that supports C/C++ expression evaluation will want to be
able to support these vector operations on vector objects too.

Vector types appear on function prototypes, so they have their own
mangling scheme in the Itanium ABI.

Other vendors have similar C/C++ extensions.  For example, Motorola’s
Altivec C/C++ Language Extensions, which predates GCC's extensions.

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.

-

In Section 2.2 Attribute Types, DW_AT_vector and
DW_AT_variable_vector_width shall be added to Table 2.2


    DW_AT_vector    | A hardware vector type


The hyperlink in the "Identifies or Specifies" column shall point to
the paragraph added to Section 5.5 below for DW_AT_vector.

In Section 5.5 Array Type Entries, replace first paragraph of
non-normative text with:


    [non-normative] Many languages share the concept of an “array,”
    which is a table of components of identical type. Furthermore,
    many architectures contain vector types which mirror the
    language concept of an array.


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 type, shall be denoted with
    DW_AT_vector. The the width of the type shall be specified as an
    array dimension and the type contained within the register must be
    a DW_TAG_base_type entry.


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

Re: [Dwarf-discuss] ISSUE: CPU vector types.

[Ben Woodard via Dwarf-discuss]

In general I like this, I will steal / plagiarize ;-) and merge it to form a V2 
Vector proposal and send it out.  

There are two things that I still am trying to settle in my mind. I can see 
both both ways and have yet to come up with fully convincing arguments either 
way.

One is: Should it be an attribute on a base type DW_AT_vector, or a type 
DW_TAG_vector. The two strongest arguments I have for the attribute vs the tag 
are:
1) this is current behavior, why change it?
2) It seems like a tag would be practically semantically identical to the 
current array. 
 
The second thing is: How important modifying the language in the DWARF operator 
section to allow the extraction of individual elements from the vector. Can 
DWARF expressions be constructed for both big endian and little endian 
architectures that allow the individual elements to be extracted as requested 
by the debuggers for these vector types when the location of the vector type 
could be in a register, or in memory. This is where I think that the people 
including you over at AMD and Intel who have been working on debugging 
vectorized code are better informed than I am. The DWARF stack and location 
descriptions does not come up as often when doing static analysis.

-ben

> On Apr 4, 2023, at 4:14 AM, Pedro Alves  wrote:
> 
> On 2023-04-04 11:09 a.m., Pedro Alves wrote:
>>> On 2023-04-04 12:22 a.m., Kyle Huey wrote:
>>>> On Mon, Apr 3, 2023 at 12:42 PM Pedro Alves via Dwarf-discuss 
>>>> >>> <mailto:dwarf-discuss@lists.dwarfstd.org>> wrote:
>>> 
>>>    Hi Ben,
>>> 
>>>>On 2023-03-24 6:19 p.m., Ben Woodard via Dwarf-discuss wrote:
>>> 
>>>> I will admit that in its current state it is a work in progress. My 
>>>> original intent was to simply
>>>> codify the existing behavior as implemented by GCC and LLVM (and probably 
>>>> other compilers) moving it
>>>> from a vendor attribute to something that was in the standard.
>>> 
>>>In light of the recent discussion, I was thinking how it would help if 
>>> the
>>>proposal was laid out in terms of vector types instead of hardware 
>>> registers.
>>> 
>>> 
>>> I think the proposed language here is a bit too C/C++ centric.
>> 
>> This is introducing the need for the attribute.  The audience is the 
>> committee, not DWARF spec readers,
>> because none of this text would end up in the spec.  It is just setting the 
>> ground.  It is true that other
>> languages have vector types as well, but I'd think that even if only C/C++ 
>> had them, that would
>> not be reason to not support the types.  But we can certainly tweak the 
>> language to cover other languages.
> 
> Here's what I would suggest.
> 
> ~
> Vector types
> 
> Some languages support vector data types, which are not possible to
> represent today in standard DWARF.  In very broad strokes, a vector is
> an array of values.  These can be allocated to a SIMD vector register,
> if available, either permanently or temporarily, and operations on
> vectors make use of SIMD instructions, again if available.
> 
> For example, as an extension to C and C++, GCC supports defining
> vector data types as described here:
> 
>  https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
> 
> In this C/C++ extension, vector types are similar to arrays, and you
> can index and initialize them similarly, but they have some important
> differences.  For example:
> 
> - C arrays automatically decay to pointers.  Vector types do not.
> 
> - You can pass vector types by value to functions, and likewise
>  functions can return vector types by value.  You can not do either
>  with C arrays.
> 
> - Vector types can be used with a subset of normal C operations: +, -,
>  *, /, unary minus, ^, |, &, ~, %.  For example, addition is defined as
>  the addition of the corresponding elements of the operands.
> 
> A debugger that supports C/C++ expression evaluation will want to be
> able to support these vector operations on vector objects too.
> 
> Vector types appear on function prototypes, so they have their own
> mangling scheme in the Itanium ABI.
> 
> Other vendors have similar C/C++ extensions.  For example, Motorola’s
> Altivec C/C++ Language Extensions, which predates GCC's extensions.
> 
> 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.
> ~
> 

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

Re: [Dwarf-discuss] ISSUE: CPU vector types.

[Ben Woodard via Dwarf-discuss]

-ben

> On Mar 30, 2023, at 1:27 PM, Pedro Alves  wrote:
> 
> On 2023-03-29 8:55 p.m., Ben Woodard via Dwarf-discuss wrote:
>> 
>> On 3/28/23 13:17, David Blaikie wrote:
> ...
>>> What DWARF should be used to describe the type of 'a'? And how does
>>> this encoding scale to all the other similar intrinsic types?
>>> 
>> As a person who has spent a crazy amount of time doing ABI work and static 
>> analysis this is what I would like: (I'm kind of assembling this by cutting 
>> and pasting and editing so please excuse minor errors like sizes and 
>> ignoring siblings. It is hand written hand-wavy DWARF)
>> 
>> *Factored out preamble to all of them:*
>> [0] base_typeabbrev: 3
>>byte_size(data1) 4
>>encoding (data1) float (4)
>>name (strp) "float"
>> [5]  base_typeabbrev: 3
>>byte_size(data1) 4
>>encoding (data1) unsigned (4)
>>name (strp) "unsigned int"
>> [8]  base_typeabbrev: 3
>>byte_size(data1) 4
>>encoding (data1) signed (4)
>>name (strp) "int"
>> [10] base_typeabbrev: 3
>>byte_size(data1) 8
>>encoding (data1) double (4)
>>name (strp) "double float"
>> [15] subprogram   abbrev: 32
>>external (flag_present) yes
>>name (string) "f"
>> [20]  formal_parameter abbrev: 15
>>  name (string) "a"
>>  type (ref4) [30]
>> 
>> *void f( float *a){}**
>> *[30] pointer_type abbrev: 5
>>byte_size(implicit_const) 8
>>type (ref4) [0]
>> 
>> *void f( float a[]){}*
>> [30] array_type abbrev: 5
>>type (ref4) [0]
>> 
> 
> In reality, the "float a[]" case above is not really an array.
> 'a' is still a pointer.  There is no such thing as passing an array by value 
> in C/C++.  The two cases above
> are defining the same function overload.  Note:
> 
> $ g++ v.cc -o -g3 -O0
> v.cc:11:6: error: redefinition of ‘void f(float*)’
>   11 | void f(float a[]) {}
>  |  ^
> v.cc:10:6: note: ‘void f(float*)’ previously defined here
>   10 | void f(float *a) {}
>  |  ^
> 
> I guess you're saying that a consumer would know that it is looking at a C or 
> c++ function, and thus is knows
> that even if the argument's type is described as an array, that it is really 
> a pointer?

Yeah basically. I should have had more emphasis saying that this is 
_how_I_would_like_it_to_be_ as a person whose introduction to DWARF was static 
analysis of ABIs. You have correctly stated how it really is. How it currently 
is. I just wish it was different so that my static analysis tools could detect 
the difference between “a head of linked list pointer” “a C array pointer” and 
all the other semantically distinct uses of C pointers.

In essence, I was trying to point out the ambiguities that this creates for 
people like me doing static analysis. One of favorite catch phrases is “DWARF 
it ain’t just for debuggers anymore”, we use it for static analysis and 
performance tools and they have slightly different needs than debuggers.

For example debuggers need location information which are in essence functions 
that work like 
   f( pc, variable) -> location

Performance tools and certain binary analysis tools really could use something 
that I call “inverted location lists” which work like: 
f( pc, location) -> variable or expression. 
This would allow us to quickly answer questions like: These instructions cause 
a huge number of L1 cache misses. Which variable accesses in those instructions 
are causing that? There are a few experts amongst us who can figure that out.  
However, making automated tools which which we can give to developers who are 
less experienced to allow them figure this out has been remarkably difficult. 
I’ve tried, a few other people have tried. The way that location lists work, it 
just doesn’t give you all the information that you need to completely reverse 
the mapping from:
   f( pc, variable) -> location
To:
  f( pc, location) -> variable.
> 
>> *void f( float a[4]){}
> 
> Here I believe '4' must be ignored by the compiler's code generator, at 
> least, the compiler can't really
> assume that 'a' points to an array with 4 elements.  The '4' is just 
> basically documentation.  Some
> compilers, s

Re: [Dwarf-discuss] ISSUE: CPU vector types.

[Ben Woodard via Dwarf-discuss]

On 3/28/23 13:17, David Blaikie wrote:

DW_AT[_GNU]_vector is best understood not as "a hardware vector register" but rather as a 
marker that "this type is eligible to be passed in hardware vector registers at function 
boundaries according to the platform ABI".

My 2c would not be to describe these in terms of
hardware/implementations (that gets confusing/blurs the line between
variable/types and locations - as you say, these things can be stored
in memory, so they aren't uniquely in registers - you might have a
member of this type in a struct passed in memory and need to know the
ABI/struct layout for that, etc), but at the source level - which the
ABI is defined in those same terms. Overloading, for instance, still
applies if these are different types - so other debugger features need
to work based on this type information.

So it seems like a simpler question is:

How should DWARF producers/consumers expect to encode the source
example Ben provided (well, simplified a bit):

#include 

void f( __m128 a){
}

What DWARF should be used to describe the type of 'a'? And how does
this encoding scale to all the other similar intrinsic types?

As a person who has spent a crazy amount of time doing ABI work and 
static analysis this is what I would like: (I'm kind of assembling this 
by cutting and pasting and editing so please excuse minor errors like 
sizes and ignoring siblings. It is hand written hand-wavy DWARF)


*Factored out preamble to all of them:*
[0] base_type    abbrev: 3
   byte_size    (data1) 4
   encoding (data1) float (4)
   name (strp) "float"
[5] base_type    abbrev: 3
   byte_size    (data1) 4
   encoding (data1) unsigned (4)
   name (strp) "unsigned int"
[8] base_type    abbrev: 3
   byte_size    (data1) 4
   encoding (data1) signed (4)
   name (strp) "int"
[10] base_type    abbrev: 3
   byte_size    (data1) 8
   encoding (data1) double (4)
   name (strp) "double float"
[15] subprogram abbrev: 32
   external (flag_present) yes
   name (string) "f"
[20]  formal_parameter abbrev: 15
     name (string) "a"
     type (ref4) [30]

*void f( float *a){}**
*[30] pointer_type abbrev: 5
   byte_size    (implicit_const) 8
   type (ref4) [0]

*void f( float a[]){}*
[30] array_type     abbrev: 5
   type (ref4) [0]

*void f( float a[4]){}
*[30] array_type     abbrev: 5
   type (ref4) [0]
[40] subrange_type    abbrev: 31
   upper_bound  (data1) 3*
*

*void f( float a[s], **unsigned s**){} // C only*
[30] array_type     abbrev: 5
   type (ref4) [0]
[40] subrange_type    abbrev: 31
   upper_bound  (data1) DW_OP_reg reg4
[50]formal_parameter abbrev: 15
     name (string) "s"
     type (ref4) [5]

*void f( __m128 a){} // floats implied*
[30] typedef  abbrev: 8
    name (strp) "__m128"
 decl_file    (data1) xmmintrin.h (2)
 decl_line    (data1) 69
 decl_column  (data1) 15
 type (ref4) [40]
[40] array_type     abbrev: 5
vector   (flag_present) yes
   type (ref4) [0]
[50] subrange_type    abbrev: 31
   upper_bound  (data1) 3*
*

*void f( __m128i a){} // integer*
[30] typedef  abbrev: 8
    name (strp) "__m128i"
 decl_file    (data1) xmmintrin.h (2)
 decl_line    (data1) 69
 decl_column  (data1) 15
 type (ref4) [40]
[40] array_type     abbrev: 5
vector   (flag_present) yes
   type (ref4) [8]
[50] subrange_type    abbrev: 31
   upper_bound  (data1) 3

*void f( __m128d a){}*
[30] typedef  abbrev: 8
    name (strp) "__m128d"
 decl_file    (data1) xmmintrin.h (2)
 decl_line    (data1) 69
 decl_column  (data1) 15
 type (ref4) [40]
[40] array_type     abbrev: 5
vector   (flag_present) yes
   type (ref4) [10]
[50] subrange_type    abbrev: 31
   upper_bound  (data1) 2

*void f( __m128u a){} // unsigned*
[30] typedef  abbrev: 8
    name (strp) "__m128u"
 decl_file    (data1) xmmintrin.h (2)
 decl_line    (data1) 69
 decl_column  (data1) 15
 type (ref4) [40]
[40] array_type     abbrev: 5
vector   (flag_present) yes
 

Re: [Dwarf-discuss] Add a mechanism for specifying subprogram return value locations (221105.1)

[Ben Woodard via Dwarf-discuss]

Thank you Kyle,

On 3/28/23 12:49, Kyle Huey wrote:
[1] Inferring the function return value location causes issues in 
other contexts and I have a DWARF issue on that (221105.1)


Let me publicly state my support for your proposal for how to specify 
the return value of a function.


I'm not sure that I would put it in 3.3.2 or 3.3.3 but I totally agree 
with the concept of specifying the location of the return value.


-ben

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

Re: [Dwarf-discuss] ISSUE: CPU vector types.

[Ben Woodard via Dwarf-discuss]

On 3/27/23 23:51, Cary Coutant wrote:

Vector registers

It has been the long standing existing practice to treat hardware
vector registers as arrays of a fundamental base type. To deliniate
these hardware register arrays from arrays in the language source they
have been given the DW_AT_GNU_vector attribute. This proposal simply
standardizes the existing behavior.

In Section 2.2 Attribute Types, DW_AT_vector and
DW_AT_variable_vector_width shall be added to Table 2.2

 
 DW_AT_vector| A hardware vector register
 DW_AT_variable_vector_width | Array bound for hardware
 | implementation defined vector register
 | width
 

I don't understand what tags this DW_AT_vector attribute would apply
to. Vector registers aren't *types*, they're *locations*, so it
doesn't really make sense to me to put this attribute on a
DW_TAG_array_type.


Maybe I should have said.

DW_AT_vector| A hardware vector register type

because what I'm talking about are types not locations. Consider a 
simple program like:


#include 

__m128 *f( __m128 a, float *b){
  __m128 *c=new __m128;
  *c=_mm_load_ps(b);
  *c+=a;
  return c;
}

Which when compiled by GCC generates DWARF like this:

 [    7c]    base_type    abbrev: 3
 byte_size    (data1) 4
 encoding (data1) float (4)
 name (strp) "float"

[   7c5]    typedef  abbrev: 8
 name (strp) "__m128"
 decl_file    (data1) xmmintrin.h (2)
 decl_line    (data1) 69
 decl_column  (data1) 15
 type (ref4) [   7d1]
 [   7d1]    array_type   abbrev: 30
 GNU_vector   (flag_present) yes
 type (ref4) [    7c]
 sibling  (ref4) [   7dd]
 [   7da]  subrange_type    abbrev: 31
   upper_bound  (data1) 3
 [   7dd]    base_type    abbrev: 3
 byte_size    (data1) 2
 encoding (data1) float (4)
 name (strp) "_Float16"
 [   7e4]    subprogram   abbrev: 32
 external (flag_present) yes
 name (string) "f"
 decl_file    (data1) vecreg.C (1)
 decl_line    (data1) 3
 decl_column  (data1) 9
 linkage_name (strp) "_Z1fDv4_fPf"
 type (ref4) [   881]
 low_pc   (addr) .text+00 
<_Z1fDv4_fPf>

 high_pc  (data8) 38 (.bss+00)
 frame_base   (exprloc)
  [ 0] call_frame_cfa
 call_all_calls   (flag_present) yes
 sibling  (ref4) [   881]
 [   808]  formal_parameter abbrev: 15
   name (string) "a"
   decl_file    (implicit_const) vecreg.C (1)
   decl_line    (implicit_const) 3
   decl_column  (data1) 19
   type (ref4) [   7c5]
   location (sec_offset) location list [    10]
   GNU_locviews (sec_offset) location list [ c]
 [   818]  formal_parameter abbrev: 15
   name (string) "b"
   decl_file    (implicit_const) vecreg.C (1)
   decl_line    (implicit_const) 3
   decl_column  (data1) 29
   type (ref4) [   886]
   location (sec_offset) location list [    22]
   GNU_locviews (sec_offset) location list [    1c]
 [   828]  variable abbrev: 33
   name (string) "c"
   decl_file    (data1) vecreg.C (1)
   decl_line    (data1) 4
   decl_column  (data1) 11
   type (ref4) [   881]
   location (sec_offset) location list [    37]
   GNU_locviews (sec_offset) location list [    35]

 [   881]    pointer_type abbrev: 5
 byte_size    (implicit_const) 8
 type (ref4) [   7c5]
 [   886]    pointer_type abbrev: 5
 byte_size    (implicit_const) 8
 type (ref4) [    7c]



  Offset: 10, Index: 4
    offset_pair 0, 15
  .text+00 <_Z1fDv4_fPf>..
  .text+0x0014 <_Z1fDv4_fPf+0x14>
    [ 0] reg17
    offset_pair 15, 26
  

Re: [Dwarf-discuss] Enhancement: Expression Operation Vendor Extensibility Opcode

[Ben Woodard via Dwarf-discuss]

I'm sorry Scott, I did not intend to hijack your proposal. In essence, I 
was saying that I support a the registry part of your proposal below. 
That has been one of the long time requests from the tool developers 
that I work with.


On 3/24/23 13:21, Linder, Scott via Dwarf-discuss wrote:

[AMD Official Use Only - General]

Background
==

The vendor extension encoding space for DWARF expression operations
accommodates only 32 unique operations. In practice, the lack of a central
registry and a desire for backwards compatibility means vendor extensions are
never retired, even when standard versions are accepted into DWARF proper. This
has produced a situation where the effective encoding space available for new
vendor extensions is miniscule today.


I understand the desire for each particular vendor opcode to have a 
semantic meaning that is fixed throughout time. This simplifies some 
areas of the DWARF parsers because they do not have to disambiguate the 
semantic meaning of a particular constant based upon the version of the 
DWARF that is being processed. This is particularly helpful when you are 
handling a an object that may be linked together containing CUs that 
were produced with different versions of the standard. This is not only 
true for DWARF Vendor expression operations, it is true of the broader 
DWARF standard.


In essence up to this point a DWARF5 enabled parser, has been be capable 
of handing DWARF{4,3} and possibly even DWARF2 without modification. I'm 
not really aware of any breakages where interpreting an older version of 
DWARF requires being aware of the DWARF version number.


Does this continue to be an goal for DWARF6? Whether or not this is 
true, we should make this explicit.


If not, it would provide an opportunity for tool developers to begin 
building the DWARF version sensitive parsers necessary to handle that in 
the cases where within an object CUs can have different versions of 
DWARF. An explicit statement of intent would also give the vendor 
compiler developers and opportunity make the decision, that with DWARF6 
they could begin to reuse or recycle vendor extensions which are no 
longer needed for whatever reason.


I personally feel like DWARF has been around for about 30 years, it is 
kind of due a flag day allowing accumulated cruft to be purged. The 
producers and consumers just need to all move together and DWARF6 may be 
a good time to do this.



To expand this encoding space we propose defining one DWARF operation in the
official encoding space which acts as a "prefix" for vendor extensions. It is
followed by a ULEB128 encoded vendor extension opcode, which is then followed
by the operands of the corresponding vendor extension operation.

This scheme opens up an infinite encoding space for arbitrary vendor
extensions, and in practical terms is no less compact than if a fixed-size
encoding were chosen, as was done for DW_LNS_extended_op. That is to say, when
compared with an alternative scheme which encodes the opcode with a single
unsigned byte: for the first 127 opcodes our approach is indistinguishable from
the alternative scheme; for the next 128 opcodes it requires one more byte than
that alternative scheme; and after 255 opcodes the alternative scheme is
exhausted.

Since vendor extension operations can have arbitrary semantics, the consumer
must understand them to be able to continue evaluating the expression. The only
use for a size operand would be for a consumer that only needs to print the
expression. Omitting a size operand makes the operation encoding more compact,
and this was deemed more important than the limited printing use case.
Therefore no ULEB128 size operand is present to provide the number of bytes of
following operands, unlike DW_LNS_extended_op.

A centralized registry of vendor extension opcodes which are in use, maintained
on the dwarfstd.org website or another suitable location, could also be
implemented as a part of this proposal. This would remove the need for vendors
to coordinate allocation themselves, and make it simpler to use more than one
vendor extension at a time. As there is support for an infinite number of
opcodes, the registration process could involve very limited review, and would
therefore pose a minimal burden to the maintainer of such a registry.


My only concern with this proposal is really, I believe that vendor 
specific extensions should be kept to a bare minimum. It makes the job 
of consumers much more difficult, especially when tools need to support 
multiple producers.


I would say from a consumer perspective, I would prefer keeping the 
range of vendor extensions smaller, possibly forcing a flag day to 
facilitate reuse of old disused encodings, and making the process of 
standardizing needed new behaviors easier and more frequent. I believe 
that there will always need to be encoding space to prototype features. 
However, I believe that the community is best served by having new 

Re: [Dwarf-discuss] ISSUE: CPU vector types.

[Ben Woodard via Dwarf-discuss]

On Mar 25, 2023, at 1:58 PM, Ron Brender  wrote:Ben,I am puzzling over your vector types proposal as well as the Tye proposal you cite. My impression is that they are hard to distinguish.The Tye proposal turns CPU vector types into base types while your proposal keeps them distinct, but then you add this additional class of types to the base types of operands in all of the types where it matters, in particular DW_OP_regval_type, DW_OP_deref_type and DW_OP_xderef_type. In both cases you end up being able to push and pop complete register contents to/from the DWARF stack. You mention a possible maximum size of 2048 bytes *currently*, but that seems likely to continue to grow over time. Is it really important to have all of the vector register contents on the DWARF stack at one time? What can be done to operate on sucha stack value? Seems like there needs to be at least a way to DW_OP_reinterpret such a value to/from a sequence of values of the element type on the stack. (If nothing else, what is the corresponding element order? IE, does the DEBUG stack grow up or down?)What if we start with the proposal where CPU vector types are not base types, then instead add operators such as DW_OP_regval_idx_type,DW_OP_deref_idx_type and DW_OP_xderef_idx_type, each of which adds one additional parameter, an index, to push or pop a single element of the vector array. Then a debugger can treat such arrays like all other arrays; operations generally iterate over the elements in the obvious way.I will have to think about this more and get back to you on that next week. I think it is a good idea at first glance and so it requires more careful consideration than I can give it on a Saturday night. However, I would like to respond to the point below.Among other things, this alternative seems like it would have few if any problems with SVE or RVV.At a higher level of discourse, I think it would be unusual for a source program vector (one-dimensional array) to ever be directly allocated in a vector register and spend its entire lifetime there, right? I do not believe that you are correct about this. The place where I see it the most is in interfaces since most of my work with DWARF has been ABI related. In the functions that I see it, the data lives its entire life in the vector register. Can I refer you to https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#id51 as a point of discussion. Intel’s platform ABI has something similar but it is less clear in this section since the vector units have undergone many generations of development from MMX through to AVX-512. If you look at functions that take these as arguments, you will see that they often exclusively operate on data in these vectors. If you look any example code that use these in arguments, I think it will see what I mean. There are also many example programs that are associated with intel vector intrinsics or ARM SVE available on the web that illustrate this. I will concede that if you look at code that is the result of autovectorization, you are more likely to see examples where data moves in and out of the vectors. If it will help, I can post code fragments and their DWARF to help demonstrate this point. Thus, these CPU vector types should generally also have a DW_AT_artificial attribute, I think. They might not even have a name but if they did it would be some kind of pseudo-name (VR@@1 or whatever). Is it expected that users will need to name these registers directly as part of debugging or is the goal to make the compiled code use of vector registers as transparent as its use of general registers? I’m either misunderstanding you or I think that you may be wrong about this point. I probably have a bias because the programmers that I work with write a lot of explicitly vectorized code. I think what you are thinking of may be simple autovectorized code. However, the people that I work with have moved through CPU autovectorized code, through to explicitly vectorized code and are now working extensively with GPUs which use vector registers for practically everything and in ways as a CPU programmer, boggled my mind the first few times that I saw them. There is nothing artificial about how they use vector registers in these cases. It is very explicitly making use of vector registers at the source language level with platform specific types. I see the DW_AT_artificial in OpenMP kernels, in lambda functions, and in a few other places and it makes sense there. I don’t think it makes sense here.Would it be helpful if I posted code fragments with the associated DWARF?As I say, I am just puzzling... RonOn Fri, Mar 24, 2023 at 2:20 PM Ben Woodard via Dwarf-discuss <dwarf-discuss@lists.dwarfstd.org> wrote:
  


  
  
I was working on this before the change of administration. 

Vector types have been around for a very long time and compilers
  use them but are not handled in the DWARF standard right on
  DWARF5. I

[Dwarf-discuss] Wiki list of vendor extensions.

[Ben Woodard via Dwarf-discuss]

That reminds me.

Tangential to Scott's request, one of the requests from the tool 
developer community that I work with is to add a new wiki article which 
lists all the vendor extensions for the various compilers. Obviously 
this would include but not be limited to the Vendor specific DWARF 
expression operations.


-ben

On 3/24/23 13:21, Linder, Scott via Dwarf-discuss wrote:

[AMD Official Use Only - General]

Background
==

The vendor extension encoding space for DWARF expression operations
accommodates only 32 unique operations. In practice, the lack of a central
registry and a desire for backwards compatibility means vendor extensions are
never retired, even when standard versions are accepted into DWARF proper. This
has produced a situation where the effective encoding space available for new
vendor extensions is miniscule today.


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

[Dwarf-discuss] ISSUE: CPU vector types.

[Ben Woodard via Dwarf-discuss]

I was working on this before the change of administration.

Vector types have been around for a very long time and compilers use 
them but are not handled in the DWARF standard right on DWARF5. I think 
that this was basically something that was overlooked and no one filed 
an issue to get it addressed in the standard.


There are two different proposals about how to handle them and I believe 
that the committee should discuss the two options and then decide a 
course of action.


At the bottom of this email is my proposal. I will admit that in its 
current state it is a work in progress. My original intent was to simply 
codify the existing behavior as implemented by GCC and LLVM (and 
probably other compilers) moving it from a vendor attribute to something 
that was in the standard. However, at the time I was working with Tony 
Tye and the people at AMD on one of their proposals toto better support 
GPUs and this involved a lot of work on the DWARF stack and the 
operations done within them. This led me to realize a problem with my 
initial proposal and that was that it didn't consider the impacts on the 
DWARF stack operations. I reworked my proposal to include changes in 
that area of the standard. Essentially it adds language to all 
operations that were limited to a base type now would also work on a 
vector type of a base type. Tony raised an objection to this and argued 
that handling vector types on the DWARF stack was not necessary. I have 
not put in the time to really come up with a counter example to that 
assertion. He may be correct. I'm personally not sure. No current 
compiler that I am aware of actually generates DWARF that makes use of 
the DWARF stack with vector types. My intuition is that there may be a 
case related to scatter gather where it could be useful to make use 
vector registers on the DWARF stack.


Tony Tye has a different proposal. 
https://github.com/t-tye/dwarf-locations/blob/main/014-vector-base-types.txt 



His proposal basically amounts to make vector types base types. I can't 
say that I disagree with that overall approach. My concerns are:


1. It breaks with existing behavior.
2. It would greatly increase the number of base types for a platform. I
   think that it would be the combinatorial expansion of all the
   available encodings and the architecture's available vector lengths.
3. There is an interaction between the Platform Specific ABI and the
   base types for an architecture. I'm not sure but I think that the PS
   ABI for the various architectures might need revision given this
   change. Given how many architectures there are
4. It would immediately allow the large vector registers on the DWARF
   stack and I fear that some DWARF stack implementations which are
   currently based on a platform's size of an INT would break. Some
   architecture's vector registers could be as large as 2048b.
5. I don't know how it will deal with hardware implementation variable
   vector lengths like ARM's SVE or RISC-V RVV. Just for reference for
   people who may not know this is a quick intro to SVE
   
https://www.stonybrook.edu/commcms/ookami/support/_docs/3%20-%20Intro%20to%20SVE.pdf

Anyway, my biggest concern is that in the DWARF6 process vector register 
types get standardized. In general I have come to respect Tony as a very 
thoughtful architect, so I would not be upset if his proposal were 
accepted over mine. I would just like to make sure that the concerns 
that I've pointed out above are considered.


--

Vector registers

It has been the long standing existing practice to treat hardware
vector registers as arrays of a fundamental base type. To deliniate
these hardware register arrays from arrays in the language source they
have been given the DW_AT_GNU_vector attribute. This proposal simply
standardizes the existing behavior.

In Section 2.2 Attribute Types, DW_AT_vector and
DW_AT_variable_vector_width shall be added to Table 2.2


    DW_AT_vector    | A hardware vector register
    DW_AT_variable_vector_width | Array bound for hardware
    | implementation defined vector register
                            | width


The hyperlink in the "Identifies or Specifies" column shall point to
the paragraph added to Section 5.5 below for DW_AT_vector and the
paragraph added to Section 5.13 below for
DW_AT_variable_vector_width.

In Section 2.5.1.2 Register values replace the description of
DW_OP_regval_type with the following:


    The DW_OP_regval_type operation provides the contents of a given
    register interpreted as a value of a given type. The first operand
    is an unsigned LEB128 number, which identifies a register whose
    contents is to be pushed onto the stack. The 

Re: [Dwarf-discuss] OTHER or arguably ENHANCEMENT: Logo

[Ben Woodard via Dwarf-discuss]

V2 now with tools:

http://ssh.bencoyote.net/~ben/DWARF_6_DRAFT_tools.png

It is kind of a menu. Pick your favorite dwarf body, your favorite 
helmet, your favorite tool. Or suggest something different. Since it is 
just a draft she just just did it over the DWARF6 mockup - we can 
discuss font later.


On 3/22/23 16:53, Cary Coutant wrote:

Before we can do anything with this, though, we'd need to make sure
your wife is willing to put her design under a Creative Commons, or
similar, license. I think Creative Commons is the right choice, as
that's what we've been using for other content recently. The standard
itself is Gnu FDL, but the website itself (at least more recent stuff)
is CC-BY.

Yeah I already talked to her about that. She's totally fine with that
idea. She's not one who spends a lot of time worrying about the nuances
of various licensing terms but rather has the practical outlook of
someone who earns money as a creative. One of the less restrictive
versions of CC makes sense. She usually turns over ownership in exchange
for payment or considers it a work for hire but this would be a donation.

I did a little more reading on CC and found that they do not recommend
using a CC license for logos. I think we'd really just want the
copyright assigned to us.


As for the license, whatever. She slapped a CC-BY-SA on it based upon 
your previous email. She doesn't have a problem transferring ownership 
to whomever/whatever but I don't think that there is a legal entity that 
can possess it and I don't feel like we want to wade into all that 
entails. It is a favor, a donation to the community.


-ben



-cary



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

Re: [Dwarf-discuss] OTHER or arguably ENHANCEMENT: Logo

[Ben Woodard via Dwarf-discuss]

On 3/22/23 14:51, Cary Coutant wrote:

Ben,

Thanks for forwarding these.

Simplification and minimization is the hot new trend in logo design.
(Well, maybe not quite so new today.) Everyone's doing it, from
Starbucks to Burger King, Shell, MasterCard, and Pringles, to name a
few.

I like the dwarf in #3, and the font in #1. I think simplifying the
logo is a good thing, and I like the simplicity of these examples, but
I think the feet (as in #1 and #3) are important. I agree with David
and Ron that a tool would be better than a weapon.

Before we can do anything with this, though, we'd need to make sure
your wife is willing to put her design under a Creative Commons, or
similar, license. I think Creative Commons is the right choice, as
that's what we've been using for other content recently. The standard
itself is Gnu FDL, but the website itself (at least more recent stuff)
is CC-BY.


Yeah I already talked to her about that. She's totally fine with that 
idea. She's not one who spends a lot of time worrying about the nuances 
of various licensing terms but rather has the practical outlook of 
someone who earns money as a creative. One of the less restrictive 
versions of CC makes sense. She usually turns over ownership in exchange 
for payment or considers it a work for hire but this would be a donation.


I was going to gather feedback for a while and get her to refine her 
ideas. Obviously the tools rather than weapons is a key element for V2. 
I didn't think of that.




(Personally, I always thought our current mascot looks more like a
Tasmanian devil wearing a Viking hat.)


I was hoping to create a bit of an iconic series over time for different 
contexts in much the same way that Lasseter's Beastie is the mascot for 
BSD. (I always had a fondness for Beastie that I never quite felt for Tux.)


-ben


-cary

On Wed, Mar 22, 2023 at 1:01 PM Ron Brender via Dwarf-discuss
 wrote:

FWIW, the "master" in the DWARF .git distro is an .eps file not .png--not that 
that really matters. I don't know
where it came from other than Michael gave it to me to use. The .eps does 
contain some Copyright lines, namely
% Copyright (c)1992-98 Corel Corporation
% All rights reserved. v8.0 r0.15
I suspect it came out of some WordPerfect sample graphics selection which he 
tweaked for DWARF use--my speculation.

None of which really addresses the question of replacing it. I am OK with 
considering a replacement but not eager to
spend much time on it.

I don't much care for any of the quickie examples offered by Ben. The stylized 
DWARF is no fun and certainly doesn't
look like a DWARF. The others are too much text and not enough little guy. And 
I agree with David that the Dwarf
should be holding a tool (the suggestion of a blacksmith hammer is cool) and 
not a weapon.

Such are my thoughts at the moment...

Ron


On Wed, Mar 22, 2023 at 1:52 PM David Blaikie via Dwarf-discuss 
 wrote:

FWIW, I like the idea/reckon it's worth a revisit.

I'd shy away from equipping the dwarves with weapons/combat imagery -
maybe a smithy's hammer (or pickaxe) would be more suitable for
tooling? (this sort of thing:
https://www.kctool.com/picard-1c-blacksmiths-hammer-with-ash-handle-1800g/
- has a simple/clear outline, square on one end, tapered on the other)

As for version-specific logos, as fun as it might be, practically I'd
be happy to settle on a consistent way to render versions - putting a
number in the upper right corner, perhaps (have the dwarf hold the
tool in their right hand, so would appear on the left of the image -
or swap version/tool around as folks see fit).

In general my personal font choice is more around example (4), but the
thick/sturdy-ness of (2) is probably more in keeping with the theme.

On Tue, Mar 21, 2023 at 2:44 PM Ben Woodard via Dwarf-discuss
 wrote:

It has been kind of tense around here for a while; let's have some fun.

The DWARF logo is quite old. There are many problems with it as a logo.

It is a png and though there appears to be several versions of it at different 
sizes it is a raster and so it doesn't scale well
The image itself looks scanned and then colored. This leads to some built in 
aliasing on a pixel level which show up badly when printed.
The color choices are not really ideal for printing and if we were going to use 
it on anything other than on a web page like a shirt or a sticker there would 
be problems.
If you look at it up close, it is not really clear.

I could probably go on and if people would like additional justification I will 
but with the new administration and the push to DWARF6, I think that we should 
consider a new logo. My wife happens to be a graphic designer 
https://cyansamone.com/ and one of the things that she does is logo design. 
When she came into my office and the DWARF5 standard was up on my screen and 
she cringed for about the 50'th time at the logo, I asked her to put together 
some ideas. In a few minutes, she came up with some opti

[Dwarf-discuss] ISSUE: update Dwarf_Version_Numbers.md for DWARF5

[Ben Woodard via Dwarf-discuss]

It looks like https://wiki.dwarfstd.org/Dwarf_Version_Numbers.md hasn't 
been brought up to date with DWARF5 yet. This table can be useful 
because the versions of different sections do not necessarily follow the 
major DWARF version.


For example, last year I had a question from a tool author where he was 
confused by the fact that .debug_line file format was only 3 even though 
he was compiling for either DWARF4 or 5 (I don't remember) on the 
command line.


While we are at it and preparing DWARF6 it would be a great hint to tool 
developers to know where they need to focus effort by keeping this table 
up to date with the evolving DWARF6.


-ben


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

[Dwarf-discuss] OTHER or arguably ENHANCEMENT: Logo

[Ben Woodard via Dwarf-discuss]

It has been kind of tense around here for a while; let's have some fun.

The DWARF logo is quite old. There are many problems with it as a logo.

1. It is a png and though there appears to be several versions of it at
   different sizes it is a raster and so it doesn't scale well
2. The image itself looks scanned and then colored. This leads to some
   built in aliasing on a pixel level which show up badly when printed.
3. The color choices are not really ideal for printing and if we were
   going to use it on anything other than on a web page like a shirt or
   a sticker there would be problems.
4. If you look at it up close, it is not really clear.

I could probably go on and if people would like additional justification 
I will but with the new administration and the push to DWARF6, I think 
that we should consider a new logo. My wife happens to be a graphic 
designer https://cyansamone.com/ and one of the things that she does is 
logo design. When she came into my office and the DWARF5 standard was up 
on my screen and she cringed for about the 50'th time at the logo, I 
asked her to put together some ideas. In a few minutes, she came up with 
some options. http://www.bencoyote.net/~ben/DWARF_logo_1.png


The fonts (all free as in beer) and images are mix and match and any 
other ideas are more than welcome. They are vector art and so they can 
be scaled. This was just a quick mockup.


I also thought it might be fun to have a DWARF6 specific logo that we 
could put on tools as they become capable of handling the new version of 
the standard. Another idea that I had but she hasn't drawn yet is the 6 
dwarves chasing a bug. She said that drawing that would take more than 
the 5 minutes she had at the moment because she would have to figure out 
what the dwarves look like in profile. 
http://www.bencoyote.net/~ben/DWARF_6_draft.png


Yeah I know that it isn't the most important thing in the world of DWARF 
but in relation to all the other miscellany that needed to change, I 
thought that we should toss this on the list.


-ben

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