llvm dev - Jul 2020 - New x86-64 micro-architecture levels

* 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.

Thanks,
Florian

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.

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.  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).
Since this is a feature crossing multiple projects - at least
glibc and GCC - sharing the source of said documentation
would be important.

So for the bike-shedding I indeed think x86-10{0,1,2,3}
or x86-{A,B,C,..}, eventually duplicating as x86_64- as
suggested by Jan is better than x86-2014 or x86-avx2.

Richard.
> Thanks,
> Florian
>

* 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?
> So for the bike-shedding I indeed think x86-10{0,1,2,3}
> or x86-{A,B,C,..}, eventually duplicating as x86_64- as
> suggested by Jan is better than x86-2014 or x86-avx2.
I'll comment separately on the prefix matter.

Thanks,
Florian

On 7/22/20 5:26 AM, Richard Biener via Libc-alpha wrote:
> So for the bike-shedding I indeed think x86-10{0,1,2,3}
> or x86-{A,B,C,..}, eventually duplicating as x86_64- as
> suggested by Jan is better than x86-2014 or x86-avx2.
Agreed. If we really want to be clear, call it a "level"
or something else that has a direct English meaning
e.g. x86-level-101. This makes it unambiguously clear
that this is some kind of step at which some kind of
features are enabled.

-- 
Cheers,
Carlos.