From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25349 invoked by alias); 13 Jul 2011 11:03:43 -0000 Received: (qmail 25338 invoked by uid 22791); 13 Jul 2011 11:03:42 -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-gx0-f175.google.com (HELO mail-gx0-f175.google.com) (209.85.161.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jul 2011 11:03:28 +0000 Received: by gxk3 with SMTP id 3so2680183gxk.20 for ; Wed, 13 Jul 2011 04:03:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.208.15 with SMTP id f15mr1110595ybg.422.1310555007479; Wed, 13 Jul 2011 04:03:27 -0700 (PDT) Received: by 10.151.144.19 with HTTP; Wed, 13 Jul 2011 04:03:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Jul 2011 11:09:00 -0000 Message-ID: Subject: Re: [patch 4/8 tree-optimization]: Bitwise or logic for fold_binary_loc. 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/msg01026.txt.bz2 On Wed, Jul 13, 2011 at 12:39 PM, Kai Tietz wrote: > 2011/7/13 Richard Guenther : >> On Wed, Jul 13, 2011 at 9:33 AM, Kai Tietz wro= te: >>> Hello, >>> >>> This patch adds support to fold_binary_loc for one-bit precision >>> typed bitwise-or expression. >> >> Seems to be a fallout of the missing TRUTH_NOT conversion as well. >> >>> ChangeLog >>> >>> 2011-07-13 =A0Kai Tietz =A0 >>> >>> =A0 =A0 =A0 =A0* fold-const.c (fold_binary_loc): Add >>> =A0 =A0 =A0 =A0support for one-bit bitwise-or optimizeation. >>> >>> Bootstrapped and regression tested with prior patches of this series >>> for x86_64-pc-linux-gnu. >>> Ok for apply? >>> >>> Regards, >>> Kai >>> >>> Index: gcc/gcc/fold-const.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- gcc.orig/gcc/fold-const.c =A0 2011-07-13 08:23:29.000000000 +0200 >>> +++ gcc/gcc/fold-const.c =A0 =A0 =A0 =A02011-07-13 08:59:04.011620200 += 0200 >>> @@ -10688,6 +10688,52 @@ fold_binary_loc (location_t loc, >>> =A0 =A0 =A0 =A0 =A0return omit_one_operand_loc (loc, type, t1, arg0); >>> =A0 =A0 =A0 =A0} >>> >>> + =A0 =A0 =A0if (TYPE_PRECISION (type) =3D=3D 1 && INTEGRAL_TYPE_P (typ= e)) >>> + =A0 =A0 =A0 =A0{ >>> + =A0 =A0 =A0 =A0 /* If arg0 is constant zero, drop it. =A0*/ >>> + =A0 =A0 =A0 =A0 if (TREE_CODE (arg0) =3D=3D INTEGER_CST && integer_ze= rop (arg0)) >>> + =A0 =A0 =A0 =A0 =A0 return non_lvalue_loc (loc, fold_convert_loc (loc= , type, arg1)); >>> + =A0 =A0 =A0 =A0 if (TREE_CODE (arg0) =3D=3D INTEGER_CST && ! integer_= zerop (arg0)) >>> + =A0 =A0 =A0 =A0 =A0 return omit_one_operand_loc (loc, type, arg0, arg= 1); >>> + >>> + =A0 =A0 =A0 =A0 /* !X | X is always true. ~X | X is always true. =A0*/ >>> + =A0 =A0 =A0 =A0 if ((TREE_CODE (arg0) =3D=3D TRUTH_NOT_EXPR >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0|| TREE_CODE (arg0) =3D=3D BIT_NOT_EXPR) >>> + =A0 =A0 =A0 =A0 =A0 =A0 && operand_equal_p (TREE_OPERAND (arg0, 0), a= rg1, 0)) >>> + =A0 =A0 =A0 =A0 =A0 return omit_one_operand_loc (loc, type, integer_o= ne_node, arg1); >>> + =A0 =A0 =A0 =A0 /* X | !X is always true. X | ~X is always true. =A0*/ >>> + =A0 =A0 =A0 =A0 if ((TREE_CODE (arg1) =3D=3D TRUTH_NOT_EXPR >>> + =A0 =A0 =A0 =A0 =A0 =A0 || TREE_CODE (arg1) =3D=3D BIT_NOT_EXPR) >>> + =A0 =A0 =A0 =A0 =A0 =A0 && operand_equal_p (arg0, TREE_OPERAND (arg1,= 0), 0)) >>> + =A0 =A0 =A0 =A0 =A0 return omit_one_operand_loc (loc, type, integer_o= ne_node, arg0); >>> + >>> + =A0 =A0 =A0 =A0 /* (X & !Y) | (!X & Y) is X ^ Y */ >>> + =A0 =A0 =A0 =A0 if (TREE_CODE (arg0) =3D=3D BIT_AND_EXPR >>> + =A0 =A0 =A0 =A0 =A0 =A0 && TREE_CODE (arg1) =3D=3D BIT_AND_EXPR) >>> + =A0 =A0 =A0 =A0 =A0 { >>> + =A0 =A0 =A0 =A0 =A0 =A0 tree a0, a1, l0, l1, n0, n1; >>> + >>> + =A0 =A0 =A0 =A0 =A0 =A0 a0 =3D fold_convert_loc (loc, type, TREE_OPER= AND (arg1, 0)); >>> + =A0 =A0 =A0 =A0 =A0 =A0 a1 =3D fold_convert_loc (loc, type, TREE_OPER= AND (arg1, 1)); >>> + >>> + =A0 =A0 =A0 =A0 =A0 =A0 l0 =3D fold_convert_loc (loc, type, TREE_OPER= AND (arg0, 0)); >>> + =A0 =A0 =A0 =A0 =A0 =A0 l1 =3D fold_convert_loc (loc, type, TREE_OPER= AND (arg0, 1)); >>> + >>> + =A0 =A0 =A0 =A0 =A0 =A0 n0 =3D fold_build1_loc (loc, TRUTH_NOT_EXPR, = type, l0); >>> + =A0 =A0 =A0 =A0 =A0 =A0 n1 =3D fold_build1_loc (loc, TRUTH_NOT_EXPR, = type, l1); >>> + >>> + =A0 =A0 =A0 =A0 =A0 =A0 if ((operand_equal_p (n0, a0, 0) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&& operand_equal_p (n1, a1, 0)) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 || (operand_equal_p (n0, a1, 0) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 && operand_equal_p (n1, a0, 0= ))) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return fold_build2_loc (loc, BIT_XOR_EXPR= , type, l0, n1); >>> + =A0 =A0 =A0 =A0 =A0 } >>> + >>> + =A0 =A0 =A0 =A0 tem =3D fold_truth_andor (loc, code, type, arg0, arg1= , op0, op1); >>> + =A0 =A0 =A0 =A0 if (tem) >>> + =A0 =A0 =A0 =A0 =A0 return tem; >>> + =A0 =A0 =A0 =A0} >>> + >>> =A0 =A0 =A0 /* Canonicalize (X & C1) | C2. =A0*/ >>> =A0 =A0 =A0 if (TREE_CODE (arg0) =3D=3D BIT_AND_EXPR >>> =A0 =A0 =A0 =A0 =A0&& TREE_CODE (arg1) =3D=3D INTEGER_CST > > Well, I wouldn't call it fallout. =A0As by this we are able to handle > things like ~(X >=3D B) and see that it can be converted to X < B. =A0The > point here is that we avoid that fold re-introduces here the TRUTH > variants for the bitwise ones (for sure some parts are redudant and > might be something to be factored out like we did for truth_andor > function). Also we catch by this patterns like ~X op ~Y and convert > them to ~(X op Y), which is just valid for one-bit precision typed X > and Y. > As in general !x is not the same as ~x, beside x has one-bit precision > integeral type. > > =A0I will adjust patches so, that for one-bit precision type we alway > use here instead BIT_NOT_EXPR (instead of TRUTH_NOT). This is > reasonable. Sorry, but no. fold-const.c should not look at 1-bitness at all. fold-const.c should special-case BOOLEAN_TYPEs - and it does that already. This patch series makes me think that it is premature given that on gimple we still mix TRUTH_NOT_EXPR and BIT_*_EXPRs. Richard.