[llvm-dev] New x86-64 micro-architecture levels

[H.J. Lu via llvm-dev]

On Thu, Jul 23, 2020 at 5:44 AM Michael Matz <matz at 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.