From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75443 invoked by alias); 12 May 2016 05:26:33 -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 57771 invoked by uid 89); 12 May 2016 05:25:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=D*1 X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 12 May 2016 05:21:29 +0000 Received: from 81-65-27-132.rev.numericable.fr (HELO laptop-mg.local) ([81.65.27.132]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 May 2016 07:21:25 +0200 Date: Thu, 12 May 2016 05:26:00 -0000 From: Marc Glisse To: Jeff Law cc: "H.J. Lu" , Richard Biener , GCC Patches Subject: Re: Simple bitop reassoc in match.pd In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SW-Source: 2016-05/txt/msg00871.txt.bz2 On Wed, 11 May 2016, Jeff Law wrote: > On 05/11/2016 10:17 AM, Marc Glisse wrote: >> The transformation seems right to me, but we are then missing another >> transformation like ~X & Y -> X ^ Y when we know that X & ~Y is 0 (the 1 >> bits of X are included in those of Y). That may not be easy with the >> limited bit tracking we have. A version limited to constant Y of the >> form 2^n-1 (i.e. 0...01...1) where X has a range included in [0, Y] may >> be simpler. > While we don't have strong bit tracking, we do track [0..1] ranges reasonably > well, so it may be worth doing. I had started writing +/* Simplify (~X & Y) to X ^ Y if we know that (X & ~Y) is 0. */ +#if GIMPLE +(simplify + (bit_and (bit_not SSA_NAME@0) INTEGER_CST@1) + (if ((get_nonzero_bits (@0) & wi::bit_not (@1)) == 0) + (bit_xor @0 @1))) +#endif but then I realized that VRP does not call the simplify machinery, so this would have to be rewritten in simplify_bit_ops_using_ranges. The good point is that we could then compute: may_be_nonzero_X & ~must_be_nonzero_Y instead of assuming that Y is a constant (not that it would change anything in practice). -- Marc Glisse