From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) by sourceware.org (Postfix) with ESMTPS id 42843385700B for ; Wed, 22 Jul 2020 14:22:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 42843385700B Received: by mail-io1-xd44.google.com with SMTP id d18so2746898ion.0 for ; Wed, 22 Jul 2020 07:22:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b+WwrCh5AiusRlcUHN97Rx8i2JVzkEf14+ObNHBQTy4=; b=I/XlpBCmZEO/P5YZNY1Z6VBJuPRMXyMN/ryDQyhn9iqyEHTnCo9D4JghrD8v0s8PtN OhxJdUnwtQqWeq5H1UjPIua8n4nLjhpqU8i1Wl8/+bWv/zYqxq6BhJirp83GCk1UBkKS lHO6dvnHMhvWJEgFJRF8SNnEn0mfgVyPsQw3pRYnUQkx5pUBeaT1sBrplgJsrf0jYZA9 UTSfhrUsYcuw4Ql5ThY0znqysQmSk2d2/d//fYuUUdFdYBt1UubNEt/P/CBy1TGPA7WO UYAXxDFH25qhV492/0HBFEJAK0Rg8Cg2EVpL1+/gFaGxoiBtBuHTe3OMyb297Ik30zfj iFkQ== X-Gm-Message-State: AOAM533mmqVb4unSts+EXJYSFWOJJFP0OVSWLcFurmqZ8iZvv0O6kIyW xPpND6NawoNSbi3rZYykm9FhuE1th7tu+FrhQxY= X-Google-Smtp-Source: ABdhPJyLUFmPYe3EzHjkGQ0uu2oRWSDPBAjM3Ok7JqMn9UHZZ/6cXDf0k6bJjvxXxzQIK28nG271JTJpRgA5RAr2+gY= X-Received: by 2002:a6b:8b86:: with SMTP id n128mr11674iod.202.1595427745159; Wed, 22 Jul 2020 07:22:25 -0700 (PDT) MIME-Version: 1.0 References: <87365zz3a6.fsf@oldenburg2.str.redhat.com> <87imegn3s0.fsf@oldenburg2.str.redhat.com> <87d04oj5vj.fsf@oldenburg2.str.redhat.com> <87365jkg6t.fsf@oldenburg2.str.redhat.com> In-Reply-To: From: "H.J. Lu" Date: Wed, 22 Jul 2020 07:21:49 -0700 Message-ID: Subject: Re: New x86-64 micro-architecture levels To: Richard Biener Cc: Florian Weimer , "gcc@gcc.gnu.org" , "libc-alpha@sourceware.org" , Dongsheng Song , Tom Stellard , "llvm-dev@lists.llvm.org" , "Mallappa, Premachandra" , "x86-64-abi@googlegroups.com" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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 14:22:29 -0000 On Wed, Jul 22, 2020 at 6:50 AM Richard Biener via Libc-alpha wrote: > > On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer wrote: > > > > * 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? > > 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.