[Dwarf-discuss] (no subject)
gbrl.keboardx86.64@gmail.com -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
[Dwarf-discuss] ISSUE: CPU vector types.
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 second
[Dwarf-discuss] Enhancement: Expression Operation Vendor Extensibility Opcode
[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. 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. Proposal 1) In Section 2.5.1.7, p38, add a new code at the end of the list: 3. DW_OP_user The DW_OP_user opcode encodes a vendor extension operation. It has at least one operand: a ULEB128 constant identifying a vendor extension operation. The remaining operands are defined by the vendor extension. The vendor extension opcode 0 is reserved and cannot be used by any vendor extension. The DW_OP_user encoding space can be understood to supplement the space defined by DW_OP_lo_user and DW_OP_hi_user that is allocated by the standard for the same purpose. 2) In Section 7.7.1, p226, add a new row to table 7.9: DW_OP_user | TBD | 1+ | ULEB128 vendor extension opcode, followed by | | | vendor-extension-defined operands -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
[Dwarf-discuss] Wiki list of vendor extensions.
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
Re: [Dwarf-discuss] Wiki list of vendor extensions.
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. David Anderson -- Benford's Corollary to Clarke's Law: "Any technology distinguishable from magic is insufficiently advanced." -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
Re: [Dwarf-discuss] Wiki list of vendor extensions.
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. David Anderson -- Benford's Corollary to Clarke's Law: "Any technology distinguishable from magic is insufficiently advanced." -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
