From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 5C1413857C6A for ; Wed, 22 Jul 2020 10:16:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5C1413857C6A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-137-y65bSW08OxaSt-VJ2jwUvg-1; Wed, 22 Jul 2020 06:16:47 -0400 X-MC-Unique: y65bSW08OxaSt-VJ2jwUvg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EB84C1009441; Wed, 22 Jul 2020 10:16:45 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-135.ams2.redhat.com [10.36.112.135]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1EDF58BEC3; Wed, 22 Jul 2020 10:16:43 +0000 (UTC) From: Florian Weimer To: Richard Biener Cc: Dongsheng Song , "gcc\@gcc.gnu.org" , "libc-alpha\@sourceware.org" , Tom Stellard , "llvm-dev\@lists.llvm.org" , "Mallappa\, Premachandra" , "x86-64-abi\@googlegroups.com" Subject: Re: New x86-64 micro-architecture levels References: <87365zz3a6.fsf@oldenburg2.str.redhat.com> <87imegn3s0.fsf@oldenburg2.str.redhat.com> <87d04oj5vj.fsf@oldenburg2.str.redhat.com> Date: Wed, 22 Jul 2020 12:16:42 +0200 In-Reply-To: (Richard Biener's message of "Wed, 22 Jul 2020 11:26:42 +0200") Message-ID: <87365jkg6t.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 10:16:52 -0000 * Richard Biener: > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc 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