From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91666 invoked by alias); 9 Feb 2018 10:28:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 91650 invoked by uid 89); 9 Feb 2018 10:28:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=D*inria.fr, certified X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Feb 2018 10:28:33 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 0298281387 for ; Fri, 9 Feb 2018 11:28:31 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEyfhfz07GAR for ; Fri, 9 Feb 2018 11:28:30 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id D6D8B81385 for ; Fri, 9 Feb 2018 11:28:30 +0100 (CET) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [patch] Do not generate libcalls to __unord[sd]f2 on PowerPC SPE Date: Fri, 09 Feb 2018 10:28:00 -0000 Message-ID: <5523688.bpAWfy1Iex@polaris> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart5605174.bgh3WlFU68" Content-Transfer-Encoding: 7Bit X-SW-Source: 2018-02/txt/msg00499.txt.bz2 This is a multi-part message in MIME format. --nextPart5605174.bgh3WlFU68 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Content-length: 839 Hi, the change 2016-05-02 Marc Glisse * match.pd (X u< X, X u> X): New transformations. has an annoying effect on targets implementing (most) unordered comparisons in hardware but not the UNORDERED operator itself, e.g. PowerPC SPE, because it makes the compiler generate unnecessary libcalls to __unord[sd]f2. The attached patch contains a trick to undo the effect of the change at the RTL level for such targets. It was tested on PowerPC SPE with a certified version of VxWorks (which provides a minimal certified libgcc) where it fixes the link failure of ACATS c45242b with optimization enabled. OK for the mainline? 2018-02-09 Eric Botcazou * optabs.c (prepare_cmp_insn): Try harder to emit a direct comparison instead of a libcall for UNORDERED. -- Eric Botcazou --nextPart5605174.bgh3WlFU68 Content-Disposition: attachment; filename="p.diff" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="p.diff" Content-length: 981 Index: optabs.c =================================================================== --- optabs.c (revision 257404) +++ optabs.c (working copy) @@ -3935,7 +3935,20 @@ prepare_cmp_insn (rtx x, rtx y, enum rtx if (methods != OPTAB_LIB_WIDEN) goto fail; - if (!SCALAR_FLOAT_MODE_P (mode)) + if (SCALAR_FLOAT_MODE_P (mode)) + { + /* Small trick if UNORDERED isn't implemented by the hardware. */ + if (comparison == UNORDERED && rtx_equal_p (x, y)) + { + prepare_cmp_insn (x, y, UNLT, NULL_RTX, unsignedp, OPTAB_WIDEN, + ptest, pmode); + if (*ptest) + return; + } + + prepare_float_lib_cmp (x, y, comparison, ptest, pmode); + } + else { rtx result; machine_mode ret_mode; @@ -3982,8 +3995,6 @@ prepare_cmp_insn (rtx x, rtx y, enum rtx prepare_cmp_insn (x, y, comparison, NULL_RTX, unsignedp, methods, ptest, pmode); } - else - prepare_float_lib_cmp (x, y, comparison, ptest, pmode); return; --nextPart5605174.bgh3WlFU68--