From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32507 invoked by alias); 11 May 2016 16:17:29 -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 32492 invoked by uid 89); 11 May 2016 16:17:29 -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,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=late X-HELO: mail2-relais-roc.national.inria.fr Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 11 May 2016 16:17:25 +0000 Received: from 81-65-27-132.rev.numericable.fr (HELO laptop-mg.local) ([81.65.27.132]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2016 18:17:22 +0200 Date: Wed, 11 May 2016 16:17:00 -0000 From: Marc Glisse To: "H.J. Lu" cc: Richard Biener , GCC Patches Subject: Re: Simple bitop reassoc in match.pd (was: Canonicalize X u< X to UNORDERED_EXPR) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SW-Source: 2016-05/txt/msg00855.txt.bz2 On Wed, 11 May 2016, H.J. Lu wrote: >>> * fold-const.c (fold_binary_loc) [(X ^ Y) & Y]: Remove and merge with... >>> * match.pd ((X & Y) ^ Y): ... this. > It caused: > > FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp2 " & 1;" 0 > > on x86. Ah, yes, logical_op_short_circuit so I didn't test it. Hmm, doesn't seem so easy. We want to compute (int)(x==0) in a branch where x is known to be in [0, 1]. VRP1 gives (int)(_Bool)(x^1). forwprop3 handles the double conversion, which gives (x^1)&1. Here the new transform applies and gives (~x)&1. VRP2 comes, and with (x^1)&1 it used to notice that this is just x^1 (remember that x is in [0, 1] in this branch), while it doesn't know what to do with (~x)&1. In the end, we get notl %eax andl $1, %eax instead of xorl $1, %eax (andn doesn't seem to have a version with an immediate) 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. We could also simplify (int)(_Bool)x to x using VRP information that x is in [0, 1], but apparently when VRP replaces x==0 with y=x^1,(_Bool)y, it does not compute a range for the new variable y, and by the time the next VRP pass comes, it is too late. In the mean time, I propose xfailing this test... -- Marc Glisse