[llvm-dev] New x86-64 micro-architecture levels
Michael Matz via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 23 05:44:32 PDT 2020
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.
Ciao,
Michael.
More information about the llvm-dev
mailing list