From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 6E1341F66F for ; Wed, 4 Nov 2020 21:59:38 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AE6273944825; Wed, 4 Nov 2020 21:59:37 +0000 (GMT) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id A125F394481E for ; Wed, 4 Nov 2020 21:59:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A125F394481E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 0A4LwLds005274; Wed, 4 Nov 2020 15:58:22 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 0A4LwKmQ005271; Wed, 4 Nov 2020 15:58:20 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 4 Nov 2020 15:58:20 -0600 From: Segher Boessenkool To: Florian Weimer Subject: Re: [PATCH v2 3/3] powerpc64le: Add glibc-hwcaps support Message-ID: <20201104215820.GV2672@gate.crashing.org> References: <87pn4zfgyh.fsf@linux.ibm.com> <874km8hxo7.fsf@oldenburg2.str.redhat.com> <87mtzyfp5g.fsf@linux.ibm.com> <87361q8kvf.fsf@oldenburg2.str.redhat.com> <20201103230255.GQ2672@gate.crashing.org> <87ft5p5xvy.fsf@oldenburg2.str.redhat.com> <20201104193627.GT2672@gate.crashing.org> <87pn4s28x6.fsf@oldenburg2.str.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pn4s28x6.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.4.2.3i 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: , Cc: libc-alpha@sourceware.org, "Paul A. Clarke" Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Wed, Nov 04, 2020 at 08:56:05PM +0100, Florian Weimer wrote: > * Segher Boessenkool: > > >> > -mcpu=power10 enables MMA. If you do not want all Power10 features, you > >> > should not use -mcpu=power10. It is that simple. > >> > >> Then we need a different name, or require MMA for the "power10" > >> glibc-hwcaps subdirectory. > > > > Or do nothing. Glibc doesn't use any MMA code, does it? This is never > > generated automatically, you need to really ask for it in your source > > code. > > glibc's internal use does not matter in this context. Programmers must > be able to drop their own libraries built with -mcpu=power10 into the > power10 subdirectory. If GCC turns on MMA by default for this switch > and glibc selects the power10 subdirectory without checking for MMA > support, then this isn't guaranteed to work. Are you saying that it is *normal* for people to put very different code into libc like this? Wow. > We have been through this with x86-64 already. I don't want to produce > the same bug. No code in libc should ever use MMA, imnsho. > >> > Since powerpc64le-linux requires Power8 or later, you always have VMX > >> > and VSX enabled there. In exactly that same way. > >> > > >> > GCC never generates anything MMA that the user did not explicitly ask > >> > for in the source code (with builtins, say), so this is not an issue. > >> > Compare this with hardware DFP. > >> > >> GCC defines __MMA__ for -mcpu=power10, and source code will evenually be > >> sensitive to that macro. > > > > That macro simply says that source code can use MMA builtins and the > > like. Is it important for glibc whether user code uses MMA? > > Yes, we can only load code that is built to use MMA unconditionally > (potentially) if the system supports MMA. > > And in the future, GCC might recognize common code patterns with > -ftree-loop-vectorize and replace them with MMA intrinsics. No, not really. Maybe 20 years from now though, sure. MMA uses its own register set. Moves to other regs are expensive. You cannot pass those MMA registers around at all, either. So sure, only load modules with MMA code if the hwcap says you have MMA, but I don't see why you would refuse power10 code without it. But, ask Tulio, of course -- I just don't see the point of having a separate hwcap for it at all, if you do not use it! > >> I think it is important that -mcpu=power10 and the "power10" > >> subdirectory mean the same thing. > > > > -mcpu=power10 means "generate code optimised for power10" (and: "it will > > probably not run on cpus not compatible to power10"). > > > > Is that what that subdir holds as well? > > Yes, that's the idea. The programmer can also drop a -mcpu=power9 > library into the power9 subdirectory. The difference to the existing > AT_PLATFORM subdirectory is that on POWER10, both subdirectories (power9 > and power10) are searched. With AT_PLATFORM on POWER10, only power10 > would be searched. (And we're also fixing a silent on-disk format > change in the way AT_PLATFORM libraries are represented in ld.so.cache.) HtH, cheers, Segher