From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25781 invoked by alias); 30 Jun 2015 07:32:26 -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 25770 invoked by uid 89); 30 Jun 2015 07:32:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f171.google.com Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 30 Jun 2015 07:32:24 +0000 Received: by obdbs4 with SMTP id bs4so1030026obd.3 for ; Tue, 30 Jun 2015 00:32:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.240.228 with SMTP id wd4mr15497153obc.79.1435649542668; Tue, 30 Jun 2015 00:32:22 -0700 (PDT) Received: by 10.76.115.167 with HTTP; Tue, 30 Jun 2015 00:32:22 -0700 (PDT) In-Reply-To: References: <4c25620c-546c-40ae-b330-3652fe25f791@BAMAIL02.ba.imgtec.org> <87mvzy4nwu.fsf@e105548-lin.cambridge.arm.com> <1434562571.18552.6.camel@ubuntu-sellcey> <87381qw4wz.fsf@googlemail.com> <1434574154.18552.15.camel@ubuntu-sellcey> <6D39441BF12EF246A7ABCE6654B023532116C02D@LEMAIL01.le.imgtec.org> <1434642321.18552.20.camel@ubuntu-sellcey> Date: Tue, 30 Jun 2015 07:35:00 -0000 Message-ID: Subject: Re: [Patch, MIPS] Enable fp-contract on MIPS and update -mfused-madd From: Richard Biener To: "Maciej W. Rozycki" Cc: Steve Ellcey , Matthew Fortune , Richard Sandiford , Richard Sandiford , Joseph Myers , "gcc-patches@gcc.gnu.org" , Catherine Moore Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg02153.txt.bz2 On Mon, Jun 29, 2015 at 6:08 PM, Maciej W. Rozycki wrote: > Richard, please have a look at my question below in a reference to your > previous statement. > > On Thu, 18 Jun 2015, Steve Ellcey wrote: > >> OK, I checked in the prequel patch and here is a new copy of the >> original patch based off of that (and with no HONOR_NAN checks in the >> fma/madd instructions). >> >> OK for checkin? > > Please see below for my notes. > >> 2015-06-18 Steve Ellcey >> >> * config.gcc (mips*-*-*): Add fused-madd.opt. > > Please use angle brackets as per > , > i.e.: > > * config.gcc : Add fused-madd.opt. > > There's no function or similar entity involved here and `mips*-*-*' is a > case value like with the C language's `switch' statement where you'd use > angle brackets too to refer to individual cases. > >> (*nmsub4_fastmath) Update condition. > > Extraneous space here. > >> diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md >> index f6912e1..4f5692c 100644 >> --- a/gcc/config/mips/mips.md >> +++ b/gcc/config/mips/mips.md > [...] >> +;; fnma is defined in GCC as (fma (neg op1) op2 op3) >> +;; (-op1 * op2) + op3 ==> -(op1 * op2) + op3 ==> -((op1 * op2) - op3) >> +;; The mips nmsub instructions implement -((op1 * op2) - op3) >> +;; This transformation means we may return the wrong signed zero >> +;; so we check HONOR_SIGNED_ZEROS. >> + >> +(define_expand "fnma4" >> + [(set (match_operand:ANYF 0 "register_operand") >> + (fma:ANYF (neg:ANYF (match_operand:ANYF 1 "register_operand")) >> + (match_operand:ANYF 2 "register_operand") >> + (match_operand:ANYF 3 "register_operand")))] >> + "(ISA_HAS_FUSED_MADD3 || ISA_HAS_FUSED_MADD4) >> + && !HONOR_SIGNED_ZEROS (mode)") > > Have you considered the alternative/complementary approach proposed by > Richard here: , > i.e. to introduce further expanders, e.g.: > > fmanM4: (neg:M (fma:M OP1 OP2 OP3)) (multiply-add, negated) > > fmsnM4: (neg:M (fma:M OP1 OP2 (neg:M OP3))) (multiply-subtract, negated) > > ? > > These patterns wouldn't need a check for !HONOR_SIGNED_ZEROS as they > match the respective hardware instructions in an exact manner. Therefore > I think they would be more useful as they would also suit software that > claims/requires full IEEE Std 754 compliance. > > Richard, do you maintain the introduction of these additional operations > would be a good idea and one you're willing to support for the purpose of > patch acceptance/approval if implemented? Yes, esp. if there is now a second architecture that has such instructions. Thanks, Richard. >> +;; fnms is defined as: (fma (neg op1) op2 (neg op3)) >> +;; ((-op1) * op2) - op3 ==> -(op1 * op2) - op3 ==> -((op1 * op2) + op3) >> +;; The mips nmadd instructions implement -((op1 * op2) + op3) >> +;; This transformation means we may return the wrong signed zero >> +;; so we check HONOR_SIGNED_ZEROS. >> + >> +(define_expand "fnms4" >> + [(set (match_operand:ANYF 0 "register_operand") >> + (fma:ANYF >> + (neg:ANYF (match_operand:ANYF 1 "register_operand")) >> + (match_operand:ANYF 2 "register_operand") >> + (neg:ANYF (match_operand:ANYF 3 "register_operand"))))] >> + "(ISA_HAS_FUSED_MADD3 || ISA_HAS_FUSED_MADD4) >> + && !HONOR_SIGNED_ZEROS (mode)") > > Same observation here. > > The change looks good to me otherwise. > > Maciej