On Wed, Jul 22, 2020 at 6:50 AM Richard Biener via Libc-alpha <libc-al...@sourceware.org> wrote: > > On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer <fwei...@redhat.com> wrote: > > > > * Richard Biener: > > > > > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc <gcc@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.
