From patchwork Fri Jul 24 11:27:00 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kyrylo Tkachov X-Patchwork-Id: 499700 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 36A5914007F for ; Fri, 24 Jul 2015 21:27:15 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=pKgSfPYn; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=UlZw0qXc3bnO0WkMat7mTIiZIDU/kvSlIM80d2GFXUOh8YYO4QKJG CSd3AMB9kOIq+W38FAff0DJqexLilMYXPN4JhYjkDfUf9ArrtELODpiZLLiOvYVU mwKPePBiWSQdCv1ztMAk6Fm2iQF4kYtWURaMShnYsREISmv5ogv5Aw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s=default; bh=xUdcLynz00mozAOLq77WtpXukhw=; b=pKgSfPYnbMaqz6p/8DeniQrR0+8T H5ErlcENV5BWmm+DHeYmB5hjZlhtfLHeNlmTtOP+3UeskSdV54sFujqkrAUjUJLm PyhlkQk/GDqTcMaZqcx+0zri1Z9wKndrzCPPv6bhBPL4auQ8Mu+DUI4f068ywXEv BBQFQal09iimSGI= Received: (qmail 43378 invoked by alias); 24 Jul 2015 11:27:08 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 43367 invoked by uid 89); 24 Jul 2015 11:27:07 -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_00, SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jul 2015 11:27:05 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-17-iN6KnI8TTgK6mj63J9ACtQ-1; Fri, 24 Jul 2015 12:27:01 +0100 Received: from [10.2.207.50] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2015 12:27:00 +0100 Message-ID: <55B22104.4050409@arm.com> Date: Fri, 24 Jul 2015 12:27:00 +0100 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Szabolcs Nagy , "gcc-patches@gcc.gnu.org" CC: Marcus Shawcroft , Ramana Radhakrishnan Subject: Re: [PATCH][ARM] PR target/66731 Fix vnmul insn with -frounding-math References: <55B21D31.5020607@arm.com> In-Reply-To: <55B21D31.5020607@arm.com> X-MC-Unique: iN6KnI8TTgK6mj63J9ACtQ-1 X-IsSubscribed: yes Hi Szabolcs, On 24/07/15 12:10, Szabolcs Nagy wrote: > (-a)*b should not be compiled to vnmul a,b with -frounding-math. > Added a new -(a*b) pattern for vnmul and the old one is only > used if !flag_rounding_math. Updated the costs too. > > This is the ARM version of > https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00300.html > > Tested with arm-none-linux-gnueabihf cross compiler. > is this OK? > > gcc/Changelog: > > 2015-07-20 Szabolcs Nagy > > PR target/66731 > * config/arm/arm.md (muldf3negdf_vfp): Handle -frounding-math. > (mulsf3negsf_vfp): Likewise. This entry is misleading. You disable two existing patterns for flag_rounding_math and you add two new patterns. The entry should reflect that. > * config/arm/arm.c (arm_new_rtx_costs): Fix NEG cost for VNMUL, > fix MULT cost with -frounding-math. > > gcc/testsuite/Changelog: > > 2015-07-20 Szabolcs Nagy > > PR target/66731 > * gcc.target/arm/vnmul-1.c: New. > * gcc.target/arm/vnmul-2.c: New. > * gcc.target/arm/vnmul-3.c: New. > * gcc.target/arm/vnmul-4.c: New. +/* { dg-options "-O2 -frounding-math -mfpu=vfp -mfloat-abi=hard" } */ + +double +foo_d (double a, double b) +{ + /* { dg-final { scan-assembler "vneg\.f64" } } */ + /* { dg-final { scan-assembler "vmul\.f64" } } */ + return -a * b; +} + +float +foo_s (float a, float b) +{ + /* { dg-final { scan-assembler "vneg\.f32" } } */ + /* { dg-final { scan-assembler "vmul\.f32" } } */ + return -a * b; +} I'd prefer if you just do a scan-assembler not "vnmul", which is what this patch really fixes. Whether the midend decides to use a pair of vneg+vmul is tangential to this patch, it's the vnmul that we're trying to avoid. Thanks, Kyrill diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md index f62ff79..214c48c 100644 --- a/gcc/config/arm/vfp.md +++ b/gcc/config/arm/vfp.md @@ -770,6 +770,17 @@ [(set (match_operand:SF 0 "s_register_operand" "=t") (mult:SF (neg:SF (match_operand:SF 1 "s_register_operand" "t")) (match_operand:SF 2 "s_register_operand" "t")))] + "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_VFP && !flag_rounding_math" + "vnmul%?.f32\\t%0, %1, %2" + [(set_attr "predicable" "yes") + (set_attr "predicable_short_it" "no") + (set_attr "type" "fmuls")] +) + +(define_insn "*mulsf3negsf_vfp" + [(set (match_operand:SF 0 "s_register_operand" "=t") + (neg:SF (mult:SF (match_operand:SF 1 "s_register_operand" "t") + (match_operand:SF 2 "s_register_operand" "t"))))] "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_VFP" "vnmul%?.f32\\t%0, %1, %2" [(set_attr "predicable" "yes") Can you give the new pattern a different name to reflect that the neg is on the outside? Something like *negmulsf3_vfp. diff --git a/gcc/testsuite/gcc.target/arm/vnmul-1.c b/gcc/testsuite/gcc.target/arm/vnmul-1.c new file mode 100644 index 0000000..0b4ca2c --- /dev/null +++ b/gcc/testsuite/gcc.target/arm/vnmul-1.c @@ -0,0 +1,18 @@ +/* { dg-do compile } */ +/* { dg-require-effective-target arm_vfp_ok } */ +/* { dg-skip-if "need fp instructions" { *-*-* } { "-mfloat-abi=soft" } { "" } } */ +/* { dg-options "-O2 -mfpu=vfp -mfloat-abi=hard" } */ Can you please add an explicit -fno-rounding-math here? That way we get a hint as to why these tests exist. Alternatively, you can rename the tests to be pr66731_1.c, pr66731_2.c etc. That way in the future we'll know what issue they're testing for. diff --git a/gcc/testsuite/gcc.target/arm/vnmul-2.c b/gcc/testsuite/gcc.target/arm/vnmul-2.c new file mode 100644 index 0000000..f9a8a5c --- /dev/null +++ b/gcc/testsuite/gcc.target/arm/vnmul-2.c @@ -0,0 +1,20 @@ +/* { dg-do compile } */ +/* { dg-require-effective-target arm_vfp_ok } */ +/* { dg-skip-if "need fp instructions" { *-*-* } { "-mfloat-abi=soft" } { "" } } */