From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6837 invoked by alias); 8 Jul 2011 14:35:38 -0000 Received: (qmail 6621 invoked by uid 22791); 8 Jul 2011 14:35:36 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-qy0-f182.google.com (HELO mail-qy0-f182.google.com) (209.85.216.182) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Jul 2011 14:35:11 +0000 Received: by qyk38 with SMTP id 38so1221616qyk.20 for ; Fri, 08 Jul 2011 07:35:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.31 with SMTP id l31mr1563509qci.226.1310135710637; Fri, 08 Jul 2011 07:35:10 -0700 (PDT) Received: by 10.229.102.10 with HTTP; Fri, 8 Jul 2011 07:35:10 -0700 (PDT) In-Reply-To: References: <4E15DB74.1080100@gnu.org> Date: Fri, 08 Jul 2011 14:40:00 -0000 Message-ID: Subject: Re: [patch tree-optimization]: [3 of 3]: Boolify compares & more From: Kai Tietz To: Richard Guenther Cc: Paolo Bonzini , 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/msg00651.txt.bz2 2011/7/8 Richard Guenther : > On Thu, Jul 7, 2011 at 6:28 PM, Kai Tietz wrote: >> 2011/7/7 Paolo Bonzini : >>> On 07/07/2011 06:07 PM, Kai Tietz wrote: >>>> >>>> + =A0/* We redo folding here one time for allowing to inspect more >>>> + =A0 =A0 complex reductions. =A0*/ >>>> + =A0substitute_and_fold (op_with_constant_singleton_value_range, >>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vrp_fold_stmt, false); >>>> + =A0/* We need to mark this second pass to avoid re-entering of same >>>> + =A0 =A0 edges for switch statments. =A0*/ >>>> + =A0in_second_pass =3D true; >>>> =A0 =A0substitute_and_fold (op_with_constant_singleton_value_range, >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vrp_fold_stmt, false); >>>> + =A0in_second_pass =3D false; >>> >>> This needs a much better explanation. >>> >>> Paolo >> >> Well, I can work on a better comment. =A0The complex reduction I mean >> here are cases like >> >> int x; >> int y; >> _Bool D1; >> _Bool D2; >> _Bool D3; >> int R; >> >> D1 =3D x[0..1] !=3D 0; >> D2 =3D y[0..1] !=3D 0; >> D3 =3D D1 & D2 >> R =3D (int) D3 >> >> (testcase is already present. See tree-ssa/vrp47.c). >> >> As VRP in first pass produces (and replaces) to: >> >> D1 =3D (_Bool) x[0..1]; >> D2 =3D (_Bool) y[0..1]; >> D3 =3D D1 & D2 >> R =3D (int) D3 >> >> Just in the second pass the reduction >> >> R =3D x[0..1] & y[0..1] > > So why wouldn't that happen during the first pass? =A0The first > pass could change the IL to > > =A0D1 =3D x[0..1] !=3D 0; > =A0D2 =3D y[0..1] !=3D 0; > =A0D3 =3D D1 & D2; > =A0R =3D x & y; > > if D3 only has a single use. No, as D3 would need a type change, and this isn't possible. If it wasn't absolutely clear, this patch to VRP is necessary after patch 2, as here D1, D2, and D3 have bool-type, and just R is of type int. >> can happen. =A0In general it is sad that VRP can't insert during pass >> new statements right now. =A0This would cause issues in range-tables, >> which aren't designed for insertations. =A0As otherwise, we could do >> also simplify things like >> >> D1 =3D x[0..1] !=3D 0; >> D2 =3D y[0..1] =3D=3D 0; >> D3 =3D D1 & D2 >> R =3D (int) D3 >> >> to >> R =3D x[0..1] & (y[0..1] ^ 1) > > Why that ^ 1? =A0And why does that confuse the range tables > if you re-use R? Because we would need to insert a new statement and this isn't allowed in VRP. See the comments in VRP and substitute_and_fold. VRP disallows to remove statements or to insert new ones. >> Regards, >> Kai