From patchwork Fri Nov 4 09:17:26 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Prathamesh Kulkarni X-Patchwork-Id: 80789 Delivered-To: patch@linaro.org Received: by 10.140.97.247 with SMTP id m110csp1048840qge; Fri, 4 Nov 2016 02:17:56 -0700 (PDT) X-Received: by 10.98.70.150 with SMTP id o22mr25098931pfi.134.1478251076181; Fri, 04 Nov 2016 02:17:56 -0700 (PDT) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id e15si15257499pga.261.2016.11.04.02.17.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 02:17:56 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-return-440406-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org; spf=pass (google.com: domain of gcc-patches-return-440406-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-440406-patch=linaro.org@gcc.gnu.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; q=dns; s=default; b=j/pxHgTm35SXCB9 s7/AlCLQewY6O+xzHW1HbvI0FKdJjDFKQsbXcIu9mvNl+9rBENuLYx6LC1S5OyBS 7jo8he33f+EtLDL8TwfLZkH0sVgeJm6aAz3eEG0Lafetf0TVNq2U1XV67cPeuEdk jARce9LtPN0oNmFqJNzMkKXWMbiY= 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 :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; s=default; bh=vyhF03WNnje6gW4leH97g Md8UEk=; b=mbZDTS92GK+Q/igDMuD2gJqsus4WyXTUMQFKAmcUJvPZ6rywjZmyc 03PJ/0oUG7e122ekT/fwqc8f+ncNaFEs0U5viefbIqS+QEl7diqpSdfOrX0lnrsv P2dUqDc6eU30jnqdimNg1QSiqebUH/6b0ERh3CBUOTMaPF8gIPdN6k= Received: (qmail 50480 invoked by alias); 4 Nov 2016 09:17:40 -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 50463 invoked by uid 89); 4 Nov 2016 09:17:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=no version=3.3.2 spammy=5196, HX-Received:Fri, 519, 6, 2 X-HELO: mail-oi0-f42.google.com Received: from mail-oi0-f42.google.com (HELO mail-oi0-f42.google.com) (209.85.218.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 Nov 2016 09:17:29 +0000 Received: by mail-oi0-f42.google.com with SMTP id 128so148736428oih.0 for ; Fri, 04 Nov 2016 02:17:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q527pKqz11lqrAY2lYML6TNV2ZyBHntz/M9BO26wqsc=; b=YusUCLezQEhgxGFcV2oNyqEAxNViMb0Pi7GYzXyJKpHyn12FjfJNvd49MSUpcjQoRF rlnnphQ48PlBqBn0mEwN2wWO2ev9kUudI2KPBXkdQBo6juQkoRCF/wNiRwnMQ5ie+Zcc EoSD9aeAYp2J3wWN9lStP5OUUKhsdSC6ASSh/tsKH4LduNQqfL/KJvDx5FTq3Tx60OgJ 0zCya7u6lVDXitOX8R7b0qZsPO+DCeVDFuOPvTo/vPvZxw/NS5CxchNhHPqBPjdgFMeB QoyYyGvvldKQQDBteiZ1EFWMTNmcbJPxw1JALnmvvtH+2KqaW51Kgh9VUUjcR9ovbcsf BqJQ== X-Gm-Message-State: ABUngveSKDdt1vz0I0nDQe36qTSuYhHSE5RwHNMwrls7efCx/17Nz+foU/WQLPLndIO8LsQZZJxhBeudSrNFY2CN X-Received: by 10.107.12.229 with SMTP id 98mr13208496iom.183.1478251047166; Fri, 04 Nov 2016 02:17:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.12.169 with HTTP; Fri, 4 Nov 2016 02:17:26 -0700 (PDT) In-Reply-To: References: From: Prathamesh Kulkarni Date: Fri, 4 Nov 2016 14:47:26 +0530 Message-ID: Subject: Re: [match.pd] Fix for PR35691 To: Richard Biener Cc: gcc Patches X-IsSubscribed: yes On 4 November 2016 at 13:41, Richard Biener wrote: > On Thu, 3 Nov 2016, Marc Glisse wrote: > >> On Thu, 3 Nov 2016, Richard Biener wrote: >> >> > > > > The transform would also work for vectors (element_precision for >> > > > > the test but also a value-matching zero which should ensure the >> > > > > same number of elements). >> > > > Um sorry, I didn't get how to check vectors to be of equal length by a >> > > > matching zero. >> > > > Could you please elaborate on that ? >> > > >> > > He may have meant something like: >> > > >> > > (op (cmp @0 integer_zerop@2) (cmp @1 @2)) >> > >> > I meant with one being @@2 to allow signed vs. Unsigned @0/@1 which was the >> > point of the pattern. >> >> Oups, that's what I had written first, and then I somehow managed to confuse >> myself enough to remove it so as to remove the call to types_match :-( >> >> > > So the last operand is checked with operand_equal_p instead of >> > > integer_zerop. But the fact that we could compute bit_ior on the >> > > comparison results should already imply that the number of elements is the >> > > same. >> > >> > Though for equality compares we also allow scalar results IIRC. >> >> Oh, right, I keep forgetting that :-( And I have no idea how to generate one >> for a testcase, at least until the GIMPLE FE lands... >> >> > > On platforms that have IOR on floats (at least x86 with SSE, maybe some >> > > vector mode on s390?), it would be cool to do the same for floats (most >> > > likely at the RTL level). >> > >> > On GIMPLE view-converts could come to the rescue here as well. Or we cab >> > just allow bit-and/or on floats as much as we allow them on pointers. >> >> Would that generate sensible code on targets that do not have logic insns for >> floats? Actually, even on x86_64 that generates inefficient code, so there >> would be some work (for instance grep finds no gen_iordf3, only gen_iorv2df3). >> >> I am also a bit wary of doing those obfuscating optimizations too early... >> a==0 is something that other optimizations might use. long >> c=(long&)a|(long&)b; (double&)c==0; less so... >> >> (and I am assuming that signaling NaNs don't make the whole transformation >> impossible, which might be wrong) > > Yeah. I also think it's not so much important - I just wanted to mention > vectors... > > Btw, I still think we need a more sensible infrastructure for passes > to gather, analyze and modify complex conditions. (I'm always pointing > to tree-affine.c as an, albeit not very good, example for handling > a similar problem) Thanks for mentioning the value-matching capture @@, I wasn't aware of this match.pd feature. The current patch keeps it restricted to only bitwise operators on integers. Bootstrap+test running on x86_64-unknown-linux-gnu. OK to commit if passes ? Thanks, Prathamesh > > Richard. 2016-11-04 Prathamesh Kulkarni PR middle-end/35691 * match.pd: Add following two patterns: (x == 0 & y == 0) -> (x | typeof(x)(y)) == 0. (x != 0 | y != 0) -> (x | typeof(x)(y)) != 0. testsuite/ * gcc.dg/pr35691-1.c: New test-case. * gcc.dg/pr35691-2.c: Likewise. * gcc.dg/pr35691-3.c: Likewise. * gcc.dg/pr35691-4.c: Likewise. diff --git a/gcc/match.pd b/gcc/match.pd index 48f7351..4f74942 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -519,6 +519,19 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (if (TYPE_UNSIGNED (type)) (bit_and @0 (bit_not (lshift { build_all_ones_cst (type); } @1))))) +/* PR35691: Transform + (x == 0 & y == 0) -> (x | typeof(x)(y)) == 0. + (x != 0 | y != 0) -> (x | typeof(x)(y)) != 0. */ + +(for bitop (bit_and bit_ior) + cmp (eq ne) + (simplify + (bitop (cmp @0 integer_zerop) (cmp @1 integer_zerop)) + (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) + && INTEGRAL_TYPE_P (TREE_TYPE (@1)) + && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1))) + (cmp (bit_ior @0 (convert @1)) { build_zero_cst (TREE_TYPE (@0)); })))) + /* Fold (A & ~B) - (A & B) into (A ^ B) - B. */ (simplify (minus (bit_and:cs @0 (bit_not @1)) (bit_and:cs @0 @1)) diff --git a/gcc/testsuite/gcc.dg/pr35691-1.c b/gcc/testsuite/gcc.dg/pr35691-1.c new file mode 100644 index 0000000..5211f815 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr35691-1.c @@ -0,0 +1,12 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-forwprop-details" } */ + +int foo(int z0, unsigned z1) +{ + int t0 = (z0 == 0); + int t1 = (z1 == 0); + int t2 = (t0 && t1); + return t2; +} + +/* { dg-final { scan-tree-dump "gimple_simplified to _\[0-9\]* = \\(int\\) z1_\[0-9\]*\\(D\\);" "forwprop1" } } */ diff --git a/gcc/testsuite/gcc.dg/pr35691-2.c b/gcc/testsuite/gcc.dg/pr35691-2.c new file mode 100644 index 0000000..90cbf6d --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr35691-2.c @@ -0,0 +1,12 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-forwprop-details" } */ + +int foo(int z0, unsigned z1) +{ + int t0 = (z0 != 0); + int t1 = (z1 != 0); + int t2 = (t0 || t1); + return t2; +} + +/* { dg-final { scan-tree-dump "gimple_simplified to _\[0-9\]* = \\(int\\) z1_\[0-9\]*\\(D\\);" "forwprop1" } } */