From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-400362-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 76243 invoked by alias); 12 Jun 2015 05:50:12 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 76232 invoked by uid 89); 12 Jun 2015 05:50:11 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2
X-HELO: mx2.suse.de
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 12 Jun 2015 05:50:10 +0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])	by mx2.suse.de (Postfix) with ESMTP id 9B829AAC1;	Fri, 12 Jun 2015 05:50:07 +0000 (UTC)
User-Agent: K-9 Mail for Android
In-Reply-To: <alpine.DEB.2.20.1506112127430.1589@laptop-mg.saclay.inria.fr>
References: <20150611110432.GY2756@redhat.com> <20150611110905.GW10247@tucnak.redhat.com> <20150611120246.GZ2756@redhat.com> <alpine.DEB.2.20.1506112127430.1589@laptop-mg.saclay.inria.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
Subject: Re: match.pd: Optimize (x & y) ^ (x | y)
From: Richard Biener <rguenther@suse.de>
Date: Fri, 12 Jun 2015 05:59:00 -0000
To: Marc Glisse <marc.glisse@inria.fr>,Marek Polacek <polacek@redhat.com>
CC: Jakub Jelinek <jakub@redhat.com>,GCC Patches <gcc-patches@gcc.gnu.org>
Message-ID: <F754CE2F-C241-4380-996E-93B9EA4A03F0@suse.de>
X-SW-Source: 2015-06/txt/msg00897.txt.bz2

On June 11, 2015 10:09:11 PM GMT+02:00, Marc Glisse <marc.glisse@inria.fr> wrote:
>On Thu, 11 Jun 2015, Marek Polacek wrote:
>
>> On Thu, Jun 11, 2015 at 01:09:05PM +0200, Jakub Jelinek wrote:
>>> What about some nop type conversions in between?
>>> int
>>> fn1 (unsigned int x, unsigned int y)
>>> {
>>>   int a = x;
>>>   int b = y;
>>>   unsigned int c = x & y;
>>>   int d = a | b;
>>>   return (int) (c ^ d);
>>> }
>>> ?  Also wonder, if some testcases for match.pd shouldn't be
>>
>> It doesn't work then.  Adding some convert?s into the pattern didn't
>help
>> either.
>
>Not judging at all whether it is desirable or not, but you might have
>hit 
>the issue that when you want several convert?, you need to use the 
>spelling convert1?, convert2?, and it stops there, while here you would
>
>probably want at least 4 (maybe 6?) for this case. You might be able to
>
>work around it with a user-defined predicate, but I keep getting errors
>
>like
>generic-match.c:6655:16: error: redeclaration of ‘tree_node* o20_pops
>[2]’
>
>If you want to reproduce the error (this is probably not good as is, it
>is 
>only provided as a reproducer)
>
>(match (nopand @0 @1)
>  (bit_and (convert1? @0) (convert2? @1))
>  (if (tree_nop_conversion_p (type, TREE_TYPE (@0))
>       && tree_nop_conversion_p (type, TREE_TYPE (@1)))))
>(match (nopior @0 @1)
>  (bit_ior (convert1? @0) (convert2? @1))
>  (if (tree_nop_conversion_p (type, TREE_TYPE (@0))
>       && tree_nop_conversion_p (type, TREE_TYPE (@1)))))
>(simplify
>  (bit_xor:c (convert1? (nopand@2 @0 @1))
>             (convert2? (nopior@3 @0 @1)))
>  (if (tree_nop_conversion_p (type, TREE_TYPE (@2))
>       && tree_nop_conversion_p (type, TREE_TYPE (@3)))
>   (bit_xor (convert @0) (convert @1))))
>
>
>fold-const.c traditionally avoided the combinatorial explosion by using
>
>strip_nops.

Yeah.  We can probably special case conditional conversions in code generation instead of lowering it.  And then go the full way and special case nop conversions so you can avoid writing the predicate as well.

Richard.