From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104301 invoked by alias); 11 Jun 2015 16:12:37 -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 104292 invoked by uid 89); 11 Jun 2015 16:12:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 11 Jun 2015 16:12:35 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id CBA443173C7; Thu, 11 Jun 2015 16:12:34 +0000 (UTC) Received: from redhat.com (ovpn-204-44.brq.redhat.com [10.40.204.44]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5BGCVhg026269 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2015 12:12:33 -0400 Date: Thu, 11 Jun 2015 16:14:00 -0000 From: Marek Polacek To: Marc Glisse Cc: GCC Patches , Richard Biener Subject: Re: match.pd: Optimize (x & y) ^ (x | y) Message-ID: <20150611161230.GB2756@redhat.com> References: <20150611110432.GY2756@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-06/txt/msg00864.txt.bz2 On Thu, Jun 11, 2015 at 05:25:30PM +0200, Marc Glisse wrote: > On Thu, 11 Jun 2015, Marek Polacek wrote: > > >I have verified this transformation on a toy testcase (tried x and y > >in the range [-1000,1000]) and it does a correct thing for all integers. > > Note that for pure bitop (only involving &|^), testing the range [0,1] is > sufficient. I'd feel safer when testing a wider range of integers ;). > >+/* (x & y) ^ (x | y) -> x ^ y */ > >+(simplify > >+ (bit_xor:c (bit_and@2 @0 @1) (bit_ior@3 @0 @1)) > > Make either bit_and or bit_ior commutative? Or do we canonicalize in a way > that makes it unnecessary? Correct: bit_and and bit_ior don't need :c here. (But the bit_xor needs it.) I've tried various ordering of x and y and all of them were optimized. Arguably I should've put more tests into the testcase... > >+ (if (single_use (@2) && single_use (@3)) > >+ (bit_xor @0 @1))) > > I don't think we should use single_use here. The result is never more > complicated than the original. Sure, it might increase register pressure a > bit in some cases, but we have not used that as a criterion for other > simplifications in match.pd yet (LLVM does though). I don't have a strong preference here but we surely use single_use in match.pd elsewhere. Marek