From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62337 invoked by alias); 16 Feb 2016 14:17:59 -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 62309 invoked by uid 89); 16 Feb 2016 14:17:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*RU:sk:smtprel, Hx-spam-relays-external:sk:smtprel, HX-HELO:sk:smtprel, H*RU:14.3.195.1 X-HELO: smtprelay.synopsys.com Received: from smtprelay2.synopsys.com (HELO smtprelay.synopsys.com) (198.182.60.111) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 16 Feb 2016 14:17:53 +0000 Received: from us02secmta1.synopsys.com (us02secmta1.synopsys.com [10.12.235.96]) by smtprelay.synopsys.com (Postfix) with ESMTP id 646CB10C0A34; Tue, 16 Feb 2016 06:17:49 -0800 (PST) Received: from us02secmta1.internal.synopsys.com (us02secmta1.internal.synopsys.com [127.0.0.1]) by us02secmta1.internal.synopsys.com (Service) with ESMTP id 178B84E213; Tue, 16 Feb 2016 06:17:49 -0800 (PST) Received: from mailhost.synopsys.com (mailhost3.synopsys.com [10.12.238.238]) by us02secmta1.internal.synopsys.com (Service) with ESMTP id EC8484E202; Tue, 16 Feb 2016 06:17:48 -0800 (PST) Received: from mailhost.synopsys.com (localhost [127.0.0.1]) by mailhost.synopsys.com (Postfix) with ESMTP id D70AA384; Tue, 16 Feb 2016 06:17:48 -0800 (PST) Received: from US01WEHTC3.internal.synopsys.com (us01wehtc3.internal.synopsys.com [10.15.84.232]) by mailhost.synopsys.com (Postfix) with ESMTP id 9EE3A381; Tue, 16 Feb 2016 06:17:48 -0800 (PST) Received: from DE02WEHTCB.internal.synopsys.com (10.225.19.94) by US01WEHTC3.internal.synopsys.com (10.15.84.232) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 16 Feb 2016 06:13:54 -0800 Received: from DE02WEMBXB.internal.synopsys.com ([fe80::95ce:118a:8321:a099]) by DE02WEHTCB.internal.synopsys.com ([::1]) with mapi id 14.03.0195.001; Tue, 16 Feb 2016 15:13:52 +0100 From: Claudiu Zissulescu To: Joern Wolfgang Rennecke , "gcc-patches@gcc.gnu.org" CC: "Francois.Bedard@synopsys.com" , "jeremy.bennett@embecosm.com" Subject: RE: [PATCH] [ARC] Add single/double IEEE precission FPU support. Date: Tue, 16 Feb 2016 14:17:00 -0000 Message-ID: <098ECE41A0A6114BB2A07F1EC238DE896617846F@DE02WEMBXB.internal.synopsys.com> References: <1454335022-21760-1-git-send-email-claziss@synopsys.com> <56B13316.9090903@amylaar.uk> <56B4AEA1.6090607@amylaar.uk> <098ECE41A0A6114BB2A07F1EC238DE8966176790@DE02WEMBXB.internal.synopsys.com> <56BADB05.4020100@amylaar.uk> <098ECE41A0A6114BB2A07F1EC238DE8966176934@DE02WEMBXB.internal.synopsys.com> <56BE6DC6.4030701@amylaar.uk> In-Reply-To: <56BE6DC6.4030701@amylaar.uk> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2016-02/txt/msg01072.txt.bz2 Thanks Joern, Committed: r233451 > -----Original Message----- > From: Joern Wolfgang Rennecke [mailto:gnu@amylaar.uk] > Sent: Saturday, February 13, 2016 12:42 AM > To: Claudiu Zissulescu; gcc-patches@gcc.gnu.org > Cc: Francois.Bedard@synopsys.com; jeremy.bennett@embecosm.com > Subject: Re: [PATCH] [ARC] Add single/double IEEE precission FPU support. >=20 >=20 >=20 > On 10/02/16 13:31, Claudiu Zissulescu wrote: > > Please find attached the amended patch for FPU instructions. > > > > Ok to apply? > +(define_insn "*cmpdf_fpu" >=20 > I'm wondering - could you compare with +zero using a literal (adding an > alternative)? > (No need to hold up the main patch, but you can consider it for a follow-= up > patch) >=20 > (define_insn "*cmpsf_fpu_uneq" > + [(set (reg:CC_FPU_UNEQ CC_REG) > + (compare:CC_FPU_UNEQ > + (match_operand:DF 0 "even_register_operand" "r") >=20 > Typo: probably should be *cmpdf_fpu_uneq >=20 > + case CC_FPUmode: > + return !((code =3D=3D LTGT) || (code =3D=3D UNEQ)); > ` > strictly speaking, this shouldn't accept unsigned comparisons, although I= can't > think of a scenario where these would be presented in this mode, and the > failure mode would just be an abort in get_arc_condition_code. >=20 > Otherwise, this is OK.