[llvm-dev] New x86-64 micro-architecture levels (original) (raw)

Florian Weimer via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 22 03:16:42 PDT 2020

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. x642010, x642014) 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 x8664- as suggested by Jan is better than x86-2014 or x86-avx2.

I'll comment separately on the prefix matter.

Thanks, Florian

More information about the llvm-dev mailing list