From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31743 invoked by alias); 20 Oct 2014 11:46:35 -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 31733 invoked by uid 89); 20 Oct 2014 11:46:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 20 Oct 2014 11:46:34 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C1AEAAD54; Mon, 20 Oct 2014 11:46:30 +0000 (UTC) Date: Mon, 20 Oct 2014 11:47:00 -0000 From: Richard Biener To: Sebastian Pop cc: gcc-patches@gcc.gnu.org, marc.glisse@inria.fr Subject: Re: [PATCH][0/n] Merge from match-and-simplify In-Reply-To: <20141017182811.GA14499@f1.c.bardezibar.internal> Message-ID: References: <20141016203852.GB29134@f1.c.bardezibar.internal> <20141017163558.GD29134@f1.c.bardezibar.internal> <20141017182811.GA14499@f1.c.bardezibar.internal> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2014-10/txt/msg01899.txt.bz2 On Fri, 17 Oct 2014, Sebastian Pop wrote: > Sebastian Pop wrote: > > Richard Biener wrote: > > > looks like > > > RTL issues and/or IVOPTs issues? > > > > I should have posted the first diff between the compilers with -fdump-tree-all: > > that would expose the problem at its root. > > Looks like this is caused by the fwprop pass: > > diff -u -r ./foo.i.087t.forwprop3 ../mas/foo.i.087t.forwprop3 > --- ./foo.i.087t.forwprop3 2014-10-17 13:17:29.985327000 -0500 > +++ ../mas/foo.i.087t.forwprop3 2014-10-17 13:17:29.308814000 -0500 > @@ -5,6 +5,8 @@ > Pass statistics: > ---------------- > > +Applying pattern match-comparison.pd:43, gimple-match.c:11747 > +gimple_simplified to if (i_20 != 99) > > Pass statistics: > ---------------- > @@ -60,7 +62,7 @@ > i_17 = i_20 + 1; > # DEBUG iD.2450 => i_17 > # DEBUG iD.2450 => i_17 > - if (i_17 != 100) > + if (i_20 != 99) > goto ; > else > goto ; Ok, so this is one effect on the thing Marc pointed out - currently no patterns (well, no but one) guards itself with has_single_use predicates. That was a conscious decision and the idea was that the caller should do this via its lattice valueization function which could look like tree valueize (tree t) { if (TREE_CODE (t) == SSA_NAME && !has_single_use (t)) return NULL_TREE; return t; } But of course doing that unconditionally would also pessimize code. Generally we'd like to avoid un-CSEing stuff in a way that cannot be CSEd again. That's a more complex condition than what can be implemented with has_single_use. You might also consider a stmt doing a_1 + a_1 where a_1 has two uses now. For Sebastians case above the issue is that we are appearantly bad at optimizing post-increment exit tests. But if you'd consider code like i_2 = i_1 + 1; b1_3 = i_2 < 100; b2_4 = i_2 > 50; if (b1_3 && b2_4) ... then it is profitable to remove i_2 by changing the two comparisons to i_2 <= 98 and i_2 > 49. I thought about doing all simplifications first without committing any simplified sequence to the IL, then scanning over the result, pruning out cases that end up pessimizing code (how exactly isn't yet clear to me). So I'm not sure what we want to do here now. I don't very much like doing things explicitely in the pattern description (nor using the "has_single_use" predicate). I suppose for the gimple_build () stuff we could restrict simplifications to the expression we are building (not simplifying with SSA defs in the IL), more exactly mimicing fold_buildN behavior. I suppose for forwprop we could use the above valueize hook (but then regress because not all patterns as implemented in forwprop guard their def stmt lookup with has_single_use...). Any opinion on this? Any idea of a "simple" cost function if you have the functions IL before and after simplifications (but without any DCE/CSE applied)? Thanks, Richard.