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: <BOOL> DW_TAG_base_type DW_AT_bit_size : 1 DW_TAG_array_type DW_AT_name : predicate_t DW_AT_byte_size : 16 DW_AT_type : <BOOL> DW_AT_tensor : yes (encoding TBD) DW_TAG_subrange_type DW_AT_type : <whatever> DW_AT_lower_bound : 0 DW_AT_upper_bound : 128 NEON/SVE/RVV ought to be determinable by knowing what kind of machine the debugger is running on (ARM/RISC-V). Or, for something like dwarfdump which might try to read a foreign-architecture ELF file, from the ELF header. (Not that dwarfdump specifically is going to care...) As for NEON vs. SVE, is there a need to differentiate them? And can it not be done by shape of the type? If all those things are eliminated, then you're back to just needing a flag: tensor vs. not-tensor. > How about: > > Table 5.4: Tensor attribute values > ------------------------------------------------------------------ > Name | Meaning > ------------------------------------------------------------------ > DW_TENSOR_default | Default encoding and semantics used by target > | architecture's vector registers > ------------------------------------------------------------------ > > The point is I believe that there are going to be flavors. Can we leave > it an enum? > > Then if SVE, and RVV end up being sufficiently different we have a way > to handle them. I also double checked and ARM V9.1 SME is now publicly > disclosed so we have at least 3 architectures that I know that have > matrix registers but the compiler support hasn't quite caught up yet. > You argued that it still should be an enum, but with only one "default" value defined. And I guess any other values that might be added later would be (or at least start as) vendor extensions. It's peculiar, and I don't think we have that anywhere else in the standard. If it ever became necessary, you can always add a 2nd attribute for it. As an example, in our Ada compiler decades ago, we did this for DW_AT_artificial. It's just a flag, so either present or not-present. We added a 2nd DW_AT_artificial_kind with a whole bunch of different enums for the various kinds our compiler generated. The point is you still can get there even if DW_AT_tensor is just a flag. Regards, Todd -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
