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=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 68F161F66F for ; Wed, 4 Nov 2020 19:56:17 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 443ED388A40F; Wed, 4 Nov 2020 19:56:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 443ED388A40F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1604519776; bh=NAfaftYwc5eW3629OvLXWqCYEztG9AVvvlSRqHfFtik=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=cx8S8N3lhFYPe3G32T21REzEXtIbio60R4WF41zlwNk5eRHIuzPF5LWBn6GfYjPt1 r6Fx0HkidX+HXCBvijGY45JccrE/cMxODKnvy+tijzCIsuq7GvWJYOQxSVVKkrU1li 2Ewr5LH5Iio7Ru9/GBQNQ6y13FjrZmrDdjBMpZvo= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id F250D3857C46 for ; Wed, 4 Nov 2020 19:56:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F250D3857C46 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-502-GYW1RYB8Mni3LmllENTzKA-1; Wed, 04 Nov 2020 14:56:09 -0500 X-MC-Unique: GYW1RYB8Mni3LmllENTzKA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7DDA557203; Wed, 4 Nov 2020 19:56:08 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-113-12.ams2.redhat.com [10.36.113.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2376419C4F; Wed, 4 Nov 2020 19:56:06 +0000 (UTC) To: Segher Boessenkool Subject: Re: [PATCH v2 3/3] powerpc64le: Add glibc-hwcaps support 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> Date: Wed, 04 Nov 2020 20:56:05 +0100 In-Reply-To: <20201104193627.GT2672@gate.crashing.org> (Segher Boessenkool's message of "Wed, 4 Nov 2020 13:36:27 -0600") Message-ID: <87pn4s28x6.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: libc-alpha@sourceware.org, "Paul A. Clarke" Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" * 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. We have been through this with x86-64 already. I don't want to produce the same bug. >> > 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. >> 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.) Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill