On Thu, Jul 23, 2020 at 5:44 AM Michael Matz <m...@suse.de> wrote: > > Hello, > > On Wed, 22 Jul 2020, Mallappa, Premachandra wrote: > > > > That's deliberate, so that we can use the same x86-* names for 32-bit > > > library selection (once we define matching micro-architecture levels > > > there). > > > > Understood. > > > > > If numbers are out, what should we use instead? > > > x86-sse4, x86-avx2, x86-avx512? Would that work? > > > > Yes please, I think we have to choose somewhere, above would be more > > descriptive > > And IMHO that's exactly the problem. These names should _not_ be > descriptive, because any description invokes a wrong feeling of precision. > E.g. what Florian already mentioned: sse4 - does it imply 4.1 and 4.2, or > avx512: what of F, CD, ER, PF, VL, DQ, BW, IFMA, VBMI, 4VNNIW, 4FMAPS, > VPOPCNTDQ, VNNI, VBMI2, BITALG, VP2INTERSECT, GFNI, VPCLMULQDQ, VAES does > that one imply (rhethorical question, list shown just to make sillyness > explicit). > > Regarding precision: I think we should rule out any mathematically correct > scheme, e.g. one in which every ISA subset gets an index and the directory > name contains a hexnumber constructed by bits with the corresponding index > being one or zero, depending on if the ISA subset is required or not: I > think we're currently at about 40 ISA subsets, and hence would end up in > names like x86-32001afff and x86-22001afef (the latter missing two subset > compared to the former). > > No, IMHO the non-vendor names should be non-descript, and either be > numbers or characters, of which I would vote for characters, i.e. A, B, C. > Obviously, as already mentioned here, the mapping of level to feature set > needs to be described in documentation somewhere, and should be maintained > by either glibc, glibc/gcc/llvm or psABI people. > > I don't have many suggestions about vendor names, be them ISA-subset > market names, or core names or company names. I will just note that using > such names has lead to an explosion of number of names without very good > separation between them. As long as we're only talking about -march= > cmdline flags that may have been okay, if silly, but under this proposal > every such name is potentially a subdirectory containing many shared > libraries, and one that potentially needs to be searched at every library > looking in the dynamic linker; so it's prudent to limit the size of this > name set as well. > > As for which subsets should or shouldn't be required in which level: I > think the current suggestions all sound good, ultimately it's always going > to be some compromise. >
We can have x86-64, x86-64-v1, x86-64-v2, ...... These pseudo names should be clearly documented. -- H.J.
