From patchwork Wed Nov 25 17:06:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marius Hillenbrand X-Patchwork-Id: 1406159 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gcc.gnu.org Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=drN99pfb; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 ozlabs.org (Postfix) with ESMTPS id 4Ch6kg2F0Mz9sSs for ; Thu, 26 Nov 2020 04:07:05 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2949B395CC12; Wed, 25 Nov 2020 17:07:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2949B395CC12 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1606324023; bh=uxkKN0mnixr5lSoMB3HkEoG76AiMMdEH1+jkEBEg6NU=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=drN99pfbU/niN4GEQd6xsKO4K1fmUuPx5wRq1jPbVOgNi/r7Yv5EMaJ9Kou1GQZ99 0fECvipIDvFsWRMVd1K7pCnujND4Kg0tBxwnCX8Tea99eb5LJwA5rjf44v7abfeaaK oAvIMqO66axZ7cm+2blMZxYD0Ia7WBNJxI2sqtE0= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from oc3353602072.ibm.com (110-221-018-212.ip-addr.vsenet.de [212.18.221.110]) by sourceware.org (Postfix) with ESMTP id 125463861826 for ; Wed, 25 Nov 2020 17:06:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 125463861826 Received: by oc3353602072.ibm.com (Postfix, from userid 1000) id DC2331760285; Wed, 25 Nov 2020 18:06:56 +0100 (CET) To: Andreas Krebbel Subject: [PATCH 0/2] IBM Z: Prepare cleanup of float express precision Date: Wed, 25 Nov 2020 18:06:21 +0100 Message-Id: <20201125170622.5032-1-mhillen@linux.ibm.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP, RDNS_DYNAMIC, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Marius Hillenbrand via Gcc-patches From: Marius Hillenbrand Reply-To: Marius Hillenbrand Cc: gcc-patches@gcc.gnu.org Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" Hi, gcc has special behavior for FLT_EVAL_METHOD on s390x that causes performance impact in some scenarios and fails to align with float_t wrt the C standard in others. These two patches prepare gcc for a cleanup to get rid of that special case, to improve standard compliance and avoid the overhead. On s390 today, float_t is defined as double while gcc by default sets FLT_EVAL_METHOD to 0 and evaluates float expressions in single-precision. To mitigate that mismatch, with -std=c99 gcc emits double precision instructions for evaluating float expressions -- at the cost of additional conversion instructions. Earlier discussions favored this behavior to maintain ABI compatibility and compliance with the C standard (that is, for -std=c99), see the discussion around https://gcc.gnu.org/legacy-ml/gcc-patches/2016-09/msg02392.html Given the performance overhead, I have reevaluated the impact of cleaning up the special behavior and changing float_t into float on s390, and now think that option to be favorable. The reason for float_t being defined as double is that the port of glibc to s390 deferred to the generic definition, which back then defaulted to double. Since then, that definition has not been changed to avoid breaking ABIs that use float_t. I found only two affected packages, clucene and ImageMagick, out of >130k Debian packages scanned, and prepared patches to avoid impact. ImageMagick's ABI has become independent of float_t on s390 since 7.0.10-39 (patch in https://github.com/ImageMagick/ImageMagick/pull/2832); patch for clucene in https://sourceforge.net/p/clucene/bugs/233/. To smoothen the transition, the first patch makes gcc's behavior configurable at compile-time with the flag --enable-s390-excess-float-precision. When the flag is enabled, gcc maintains the current behavior. By default, configure will test glibc's behavior: if glibc ties float_t to double, configure will enable the flag and maintain the current behavior. Otherwise, it will disable the flag and drop the special behavior. Bootstrapped and regtested on s390x, both with a conventional and a modified glibc. Bootstrapped and regtested on x86-64. Inspected the generated headers on both targets. Marius Hillenbrand (2): IBM Z: Configure excess precision for float at compile-time gcc/testsuite/s390: Add test cases for float_t gcc/config/s390/s390.c | 27 ++++++++++---- gcc/configure.ac | 45 +++++++++++++++++++++++ gcc/doc/install.texi | 10 +++++ gcc/testsuite/gcc.target/s390/float_t-1.c | 15 ++++++++ gcc/testsuite/gcc.target/s390/float_t-2.c | 13 +++++++ 5 files changed, 103 insertions(+), 7 deletions(-) create mode 100644 gcc/testsuite/gcc.target/s390/float_t-1.c create mode 100644 gcc/testsuite/gcc.target/s390/float_t-2.c