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

[H.J. Lu via llvm-dev]

On Wed, Jul 22, 2020 at 6:50 AM Richard Biener via Libc-alpha
<libc-alpha at sourceware.org> wrote:
>
> On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer <fweimer at redhat.com> wrote:
> >
> > * Richard Biener:
> >
> > > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc <gcc at gcc.gnu.org> wrote:
> > >>
> > >> * Dongsheng Song:
> > >>
> > >> > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I
> > >> > recommend using isa tags by year (e.g. x64_2010, x64_2014) like the
> > >> > python's platform tags (e.g. manylinux2010, manylinux2014).
> > >>
> > >> I started out with a year number, but that was before the was Level A.
> > >> Too many new CPUs only fall under level A unfortunately because they do
> > >> not even have AVX.  This even applies to some new server CPU designs
> > >> released this year.
> > >>
> > >> I'm concerned that putting a year into the level name suggests that
> > >> everything main-stream released after that year supports that level, and
> > >> that's not true.  I think for manylinux, it's different, and it actually
> > >> works out there.  No one is building a new GNU/Linux distribution that
> > >> is based on glibc 2.12 today, for example.  But not so much for x86
> > >> CPUs.
> > >>
> > >> If you think my worry is unfounded, then a year-based approach sounds
> > >> compelling.
> > >
> > > I think the main question is whether those levels are supposed to be
> > > an implementation detail hidden from most software developer or
> > > if people are expected to make concious decisions between
> > > -march=x86-100 and -march=x86-101.  Implementation detail
> > > for system integrators, that is.
> >
> > Anyone who wants to optimize their software something that's more
> > current than what was available in 2003 has to think about this in some
> > form.
> >
> > With these levels, I hope to provide a pre-packaged set of choices, with
> > a consistent user interface, in the sense that -march= options and file
> > system locations match.  Programmers will definitely encounter these
> > strings, and they need to know what they mean for their users.  We need
> > to provide them with the required information so that they can make
> > decisions based on their knowledge of their user base.  But the ultimate
> > decision really has to be a programmer choice.
> >
> > I'm not sure if GCC documentation or glibc documentation would be the
> > right place for this.  An online resource that can be linked to directly
> > seems more appropriate.
> >
> > Apart from that, there is the more limited audience of general purpose
> > distribution builders.  I expect they will pick one of these levels to
> > build all the distribution binaries, unless they want to be stuck in
> > 2003.  But as long they do not choose the highest level defined,
> > programmers might still want to provide optimized library builds for
> > run-time selection, and then they need the same guidance as before.
> >
> > > If it's not merely an implementation detail then names without
> > > any chance of providing false hints (x86-2014 - oh, it will
> > > run fine on the CPU I bought in 2015; or, x86-avx2 - ah, of
> > > course I want avx2) is better.  But this also means this feature
> > > should come with extensive documentation on how it is
> > > supposed to be used.  For example we might suggest ISVs
> > > provide binaries for all architecture levels or use IFUNCs
> > > or other runtime CPU selection capabilities.
> >
> > I think we should document the mechanism as best as we can, and provide
> > intended use cases.  We shouldn't go as far as to tell programmers what
> > library versions they must build, except that they should always include
> > a fallback version if no optimized library can be selected.
> >
> > Describing the interactions with IFUNCs also makes sense.
> >
> > But I think we should not go overboard with this.  Historically, we've
> > done not such a great job with documenting toolchain features, I know,
> > and we should do better now.  I will try to write something helpful, but
> > it should still match the relative importance of this feature.
> >
> > > It's also required to provide a (extensive?) list of SKUs that fall
> > > into the respective categories (probably up to CPU vendors to amend
> > > those).
> >
> > I'm afraid, but SKUs are not very useful in this context.
> > Virtualization can disable features (e.g., some cloud providers
> > advertise they use certain SKUs, but some features are not available to
> > guests), and firmware updates have done so as well.  I think the only
> > way is to document our selection criteria, and encourage CPU vendors to
> > enhance their SKU browsers so that you can search by the (lack of)
> > support for certain CPU features.
> >
> > The selection criteria I suggested should not be affected by firmware
> > and microcode updates at least (I took that into consideration), but
> > it's just not possible to achieve virtualization and kernel version
> > independence, given that some features based on which we want to make
> > library selections demand kernel and hypervisor support.
> >
> > > Since this is a feature crossing multiple projects - at least
> > > glibc and GCC - sharing the source of said documentation
> > > would be important.
> >
> > Technically, the GCC web site would work for me.  It's not a wiki.  It's
> > not CVS.  We can update it outside of release cycle.  We are not forced
> > to use the GFDL with Invariant Sections.  It doesn't end up in our
> > product documentation, where it would be confusing if it discusses
> > unsupported CPUs.
> >
> > Everything that can be installed locally becomes outdated and
> > problematic.  The psABI supplement is a PDF document, so we can't easily
> > link to the appropriate section.  The specification found there would
> > also not be targeted at programmers, but rather at compiler and dynamic
> > linker writers.
> >
> > Did you have something else in mind?
>
> Not really - the whole stuff just adds to the ways ISV could optimize
> their binaries all of which are not very well documented in a place
> that discusses such optimization ...
>
> But yeah, extensively documenting all the ways and reasons
> to optimize binaries is certainly out-of-scope for the task of
> adding just one other way.
>
> So a website works for me.  Having a source representation
> of said website that is easy to embed into a whitepaper or
> even GCCs texi documentation for example would of course
> be nice.

We made up -march=x86-64.   We can extend pseudo x86-64
with more variants.


-- 
H.J.