From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 5D612397082C for ; Wed, 28 Apr 2021 08:42:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5D612397082C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Paul.Zimmermann@inria.fr IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ALfjgMKzWTYGZWb9UaqhrKrPwn71zdoIgy1kn?= =?us-ascii?q?xilNYDZSddGVkN3roe8S0gX6hC1UdHYrn92BP6foewK6ybde544NMbC+GDT3oW?= =?us-ascii?q?fAFvAF0aLO4R3FXxf/+OlUyLt6f8FFY+HYIFBmga/BgDWQPM0nxLC8n5yAocf7?= =?us-ascii?q?4zNTQRpxa6dmhj0VNi++HldtTAdLQboVfaDsg/ZvnDardXQJYsnTPBBsNdTrnN?= =?us-ascii?q?HTkYKjXBhuPX8awTKDkC+y7/rCGwWYty1uMQ9n+7sk/GTf+jaU2oyYr/q5xhXA?= =?us-ascii?q?vlWjjKh+pd2J8LV+Lf3JrNMUJDXqggOBf59gRLWGgTAwrIiUmTIXrOU=3D?= X-IronPort-AV: E=Sophos;i="5.82,257,1613430000"; d="scan'208";a="379886295" Received: from tomate.loria.fr (HELO tomate) ([152.81.10.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2021 10:42:25 +0200 Date: Wed, 28 Apr 2021 10:42:25 +0200 Message-Id: From: Paul Zimmermann To: Florian Weimer Cc: libc-alpha@sourceware.org In-Reply-To: <87sg3ake7i.fsf@oldenburg.str.redhat.com> (message from Florian Weimer on Wed, 28 Apr 2021 10:25:53 +0200) Subject: Re: use of fma References: <87sg3ake7i.fsf@oldenburg.str.redhat.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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, 28 Apr 2021 08:42:29 -0000 Dear Florian, > > However, on PowerPC __FP_FAST_FMA is defined without -march=native: > > > > pzimmermann@drac-12:~$ gcc -O2 -g -dM -E -xc /dev/null | grep -q __FP_FAST_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. /proc/cpuinfo says POWER8NVL, altivec supported and config.log: uname -r = 4.19.0-16-powerpc64le > > Would it make sense to add -march=native 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 “ifunc-fma” in the source tree for examples. > 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=x86-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. However this is quite technical and not easily accessible to the average user. I understand that with default configure, the binary produced should run on any x86_64. What I suggest is a configure option which would take advantage of all nice features available on the processor where we compile, with no guarantee whatsoever that it runs on any other processor. In the above case the -march=x86-64-v3 option would be added by configure automatically. Paul