From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id F3BA9393A41F for ; Wed, 28 Apr 2021 08:25:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F3BA9393A41F 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-229-GUvkanJDPBCWK67otM9MlA-1; Wed, 28 Apr 2021 04:25:25 -0400 X-MC-Unique: GUvkanJDPBCWK67otM9MlA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CF47F8049CB; Wed, 28 Apr 2021 08:25:24 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-20.ams2.redhat.com [10.36.113.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 04F6D6A8F7; Wed, 28 Apr 2021 08:25:23 +0000 (UTC) From: Florian Weimer To: Paul Zimmermann Cc: libc-alpha@sourceware.org Subject: Re: use of fma References: Date: Wed, 28 Apr 2021 10:25:53 +0200 In-Reply-To: (Paul Zimmermann's message of "Wed, 28 Apr 2021 09:23:51 +0200") Message-ID: <87sg3ake7i.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, 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, 28 Apr 2021 08:25:29 -0000 * Paul Zimmermann: > However, on PowerPC __FP_FAST_FMA is defined without -march=3Dnative: > > pzimmermann@drac-12:~$ gcc -O2 -g -dM -E -xc /dev/null | grep -q __FP_FAS= T_FMA > pzimmermann@drac-12:~$ echo $? > 0 I assume that this is powerpc64le, which has a POWER8 baseline. The switch to little endian neatly eliminated requirements for backwards compatibility. > Would it make sense to add -march=3Dnative to CFLAGS, or to add an option > like --enable-fma to configure? This is already covered by the existing mechanisms for compiler flag changes. The problem is that not all x86 CPUs currently in production support FMA. We aren't even at the stage yet where we could discuss phasing out support for old CPUs. So building everything to require FMA by default would break things for users. We already have some FMA-using function variants selected by IFUNC resolvers. Search for =E2=80=9Cifunc-fma=E2=80=9D in the source tree for e= xamples. More could be added if beneficial. If you have FMA-capable hardware and want to build glibc to take advantage of it unconditionally (without IFUNCs), use GCC 11 and -march=3Dx86-64-v3. It should be compatible with all such CPUs, and the build will also use additional CPU features not present in the x86-64 baseline specification. Thanks, Florian