Re: [Dwarf-discuss] Wiki list of vendor extensions.

[Mark Wielaard via Dwarf-discuss]

Hi,

On Fri, Mar 24, 2023 at 05:21:20PM -0700, David Anderson via Dwarf-discuss 
wrote:
> On 3/24/23 13:56, Ben Woodard via Dwarf-discuss wrote:
> >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.
> 
> The LLVM folks and myself have tried to make vendor extensions known.
> At least the names.
> 
> https://www.prevanders.net/dwarf.h
> 
> is my attempt (flawed, no doubt).
> It's not quite clear what you might mean to have in a wiki
> article about each name.

elfutils has a list of vendor extensions recognized (but not always
handled): https://sourceware.org/elfutils/DwarfExtensions

Maybe we can combine that information into a new wiki.dwarfstd.org
article?

Cheers,

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

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

[Ron Brender via Dwarf-discuss]

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 such
a 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.

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

As I say, I am just puzzling...

Ron

On 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 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 th

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  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 think that this was basic