From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5260 invoked by alias); 13 Jul 2011 11:56:29 -0000 Received: (qmail 5252 invoked by uid 22791); 13 Jul 2011 11:56:28 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yi0-f47.google.com (HELO mail-yi0-f47.google.com) (209.85.218.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jul 2011 11:55:54 +0000 Received: by yib18 with SMTP id 18so2711377yib.20 for ; Wed, 13 Jul 2011 04:55:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.114.11 with SMTP id m11mr1102343ybc.137.1310558153601; Wed, 13 Jul 2011 04:55:53 -0700 (PDT) Received: by 10.151.144.19 with HTTP; Wed, 13 Jul 2011 04:55:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Jul 2011 12:14:00 -0000 Message-ID: Subject: Re: [patch 1/8 tree-optimization]: Bitwise logic for fold_truth_not_expr From: Richard Guenther To: Kai Tietz Cc: GCC Patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2011-07/txt/msg01032.txt.bz2 On Wed, Jul 13, 2011 at 1:08 PM, Kai Tietz wrote: > 2011/7/13 Richard Guenther : >> On Wed, Jul 13, 2011 at 11:04 AM, Kai Tietz wr= ote: >>> Sorrty, the TRUTH_NOT_EXPR isn't here the point at all. The underlying >>> issue is that fold-const re-inttroduces TRUTH_AND/OR and co. >> >> I'm very sure it doesn't re-constrct TRUTH_ variants out of thin air >> when you present it with BIT_ variants as input. > > Well, look into fold-const's fold_binary_loc function and see > > =A0/* ARG0 is the first operand of EXPR, and ARG1 is the second operand. > > =A0 =A0 First check for cases where an arithmetic operation is applied to= a > =A0 =A0 compound, conditional, or comparison operation. =A0Push the arith= metic > =A0 =A0 operation inside the compound or conditional to see if any folding > =A0 =A0 can then be done. =A0Convert comparison to conditional for this p= urpose. > =A0 =A0 The also optimizes non-constant cases that used to be done in > =A0 =A0 expand_expr. > > =A0 =A0 Before we do that, see if this is a BIT_AND_EXPR or a BIT_IOR_EXP= R, > =A0 =A0 one of the operands is a comparison and the other is a comparison= , a > =A0 =A0 BIT_AND_EXPR with the constant 1, or a truth value. =A0In that ca= se, the > =A0 =A0 code below would make the expression more complex. =A0Change it t= o a > =A0 =A0 TRUTH_{AND,OR}_EXPR. =A0Likewise, convert a similar NE_EXPR to > =A0 =A0 TRUTH_XOR_EXPR and an EQ_EXPR to the inversion of a TRUTH_XOR_EXP= R. =A0*/ > > =A0if ((code =3D=3D BIT_AND_EXPR || code =3D=3D BIT_IOR_EXPR > =A0 =A0 =A0 || code =3D=3D EQ_EXPR || code =3D=3D NE_EXPR) > =A0 =A0 =A0&& ((truth_value_p (TREE_CODE (arg0)) > =A0 =A0 =A0 =A0 =A0 && (truth_value_p (TREE_CODE (arg1)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 || (TREE_CODE (arg1) =3D=3D BIT_AND_EXPR > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 && integer_onep (TREE_OPERAND (arg1, = 1))))) > =A0 =A0 =A0 =A0 =A0|| (truth_value_p (TREE_CODE (arg1)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0&& (truth_value_p (TREE_CODE (arg0)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|| (TREE_CODE (arg0) =3D=3D BIT_AND_EX= PR > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&& integer_onep (TREE_OPERAND = (arg0, 1))))))) > =A0 =A0{ > =A0 =A0 =A0tem =3D fold_build2_loc (loc, code =3D=3D BIT_AND_EXPR ? TRUTH= _AND_EXPR > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : code =3D=3D BIT_IOR_EXP= R ? TRUTH_OR_EXPR > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : TRUTH_XOR_EXPR, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 boolean_type_node, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fold_convert_loc (loc, bo= olean_type_node, arg0), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fold_convert_loc (loc, bo= olean_type_node, arg1)); > > =A0 =A0 =A0if (code =3D=3D EQ_EXPR) > =A0 =A0 =A0 =A0tem =3D invert_truthvalue_loc (loc, tem); > > =A0 =A0 =A0return fold_convert_loc (loc, type, tem); > =A0 =A0} > > Here unconditionally TRUTH_AND/TRUTH_OR gets introduced, if operands > are of kind truth. =A0This is btw the point, why you see that those > cases are handled. =A0But as soon as this part is turned off for BIT_- > IOR/AND, we need to do the folding for 1-bit precision case explicit. First of all this checks for a quite complex pattern - where do we pass such complex pattern from the gimple level to fold? For the EQ/NE_EXPR case forwprop probably might be able to feed it that, but then how does it go wrong? The above could also simply be guarded by !in_gimple_form. Richard.