From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15706 invoked by alias); 19 May 2011 13:30:49 -0000 Received: (qmail 15697 invoked by uid 22791); 19 May 2011 13:30:47 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 May 2011 13:30:32 +0000 Received: by qwh5 with SMTP id 5so1530595qwh.20 for ; Thu, 19 May 2011 06:30:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.218 with SMTP id k26mr2342291qci.270.1305811831376; Thu, 19 May 2011 06:30:31 -0700 (PDT) Received: by 10.229.33.209 with HTTP; Thu, 19 May 2011 06:30:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 May 2011 15:28:00 -0000 Message-ID: Subject: Re: [patch tree-ssa-reassoc.c]: Better reassoication for comparision and boolean-logic From: Kai Tietz To: Richard Guenther 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-05/txt/msg01386.txt.bz2 2011/5/19 Richard Guenther : > On Thu, May 19, 2011 at 3:08 PM, Kai Tietz wrot= e: >> 2011/5/19 Richard Guenther : >>> On Thu, May 19, 2011 at 2:59 PM, Kai Tietz wr= ote: >>>> 2011/5/19 Richard Guenther : >>>>> On Thu, May 19, 2011 at 2:48 PM, Kai Tietz = wrote: >>>>>> Hello, >>>>>> >>>>>> This patch improves reassociation folding for comparision. It expands >>>>>> expressions within binary-AND/OR expression like (X | Y) =3D=3D 0 to= (X =3D=3D >>>>>> 0 && Y =3D=3D 0) >>>>>> and (X | Y) !=3D 0 to (X !=3D 0 || Y !=3D 0). =A0This is necessary t= o allow >>>>>> better reassociation >>>>>> on weak pre-folded logical expressions. =A0This unfolding gets undone >>>>>> anyway later by pass, >>>>>> so no disadvantage gets introduced. >>>>>> Also while going through BB-list, it tries to do some little >>>>>> type-sinking for SSA sequences >>>>>> like "D1 =3D (type) bool1; D2 =3D (type) bool2; D3 =3D D1 & D2;' to = 'D1 =3D >>>>>> bool1 & bool2; D2 =3D (type) D1;'. >>>>>> This folding has the advantage to see better through intermediate >>>>>> results with none-boolean type. >>>>>> The function eliminate_redundant_comparison () got reworded so, that >>>>>> doesn't break in all cases. >>>>>> It now continues to find duplicates and tries to find inverse variant >>>>>> (folded to constant). By this >>>>>> change we don't combine possible weak optimizations too fast, before >>>>>> we can find and handle >>>>>> inverse or duplicates. >>>>> >>>>> sinking casting belongs not here but instead to tree-ssa-forwprop. >>>>> I'm not sure that a !=3D 0 | b !=3D 0 is the better canonical variant= than >>>>> a | b !=3D 0 though. >>>>> >>>>> is_boolean_compatible_type_p looks like a strange remanent. >>>>> >>>>> Richard. >>>> >>>> Well, a | b !=3D 0 is for sure more optimal, but for reassociation we >>>> need to see the unfolded variant temporary. This is necessary as >>>> fold-const can't see through SSA statements. =A0But this kind of >>>> expansion should be reversed then by pass to the form (a | b) !=3D 0 >>>> back. >>> >>> ? =A0fold-const shouldn't deal with this at all as we are in gimple and= in >>> SSA form. =A0Surely re-association comes to play only with chains of >>> the above with more than two operands. >>> >>> Richard. >>> >>>> >>>> Regards, >>>> Kai >>>> >>> >> >> The issue you can see by testcase binop_tor4.c, as here are the >> intermediate variables d and e (with int type) are destroying the >> reassociation pass. This testcase for example needs this sinking. > > hoisting would work equally well Well, but just if then all operands in combined BIT_AND/OR block are getting hoisting. And well, there might be still some cases where we wouldn't find the equivalent. As hoisting leads to following sequences, eg: D1 =3D a !=3D 0; D2 =3D b !=3D 0; D3 =3D a =3D=3D 0; D4 =3D b =3D=3D 0; D5 =3D (long) D1 D6 =3D (long) D2 D7 =3D (long) D3 D8 =3D (long) D4 D9 =3D D5 & D6; D10 =3D D8 & D9 D11 =3D D9 & D10; which means that comparision folding will never will happen as the statement passed to fold algorithm is a cast to a comparison and not the comparison itself. So sinking looks more sane IMHO. Regards, Kai