From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9017 invoked by alias); 13 Jun 2011 19:07:08 -0000 Received: (qmail 9004 invoked by uid 22791); 13 Jun 2011 19:07:07 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Jun 2011 19:06:50 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 01DE09AC84C; Mon, 13 Jun 2011 21:06:48 +0200 (CEST) Date: Mon, 13 Jun 2011 19:44:00 -0000 From: Jan Hubicka To: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: Cgraph alias reorg 8/14 (ipa-cp and ipa-prop update) Message-ID: <20110613190648.GC18043@kam.mff.cuni.cz> References: <20110610145543.GF28776@kam.mff.cuni.cz> <20110613172707.GA30874@virgil.arch.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110613172707.GA30874@virgil.arch.suse.de> User-Agent: Mutt/1.5.18 (2008-05-17) 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-06/txt/msg00993.txt.bz2 > Hi, > > On Fri, Jun 10, 2011 at 04:55:43PM +0200, Jan Hubicka wrote: > > Hi, > > > this patch updated ipa-cp and ipa-prop for aliases. It is basically > > easy - we don't analyze nodes represneting aliases and when > > propagating we skip them, like everywhere else. > > > > There are two problems I noticed. First we should not propagate > > through calls that are overwritable. When non-overwritable function > > A has overwritable alias B, we should propagate through calls to A, > > but not throug calls to B. As discussed on IRC it is probably best > > to zap the jump functions in question at IPA stage (because at > > analysis stage it is not clear at all if the alias will end up > > overwritable with LTO). > > > > OK. Nevertheless, I'd prefer to do this in context of the new > IPA-CP. Yep, lets see how much work will be to get new ipa-cp in. I will try to look into it more this week. > > > Similar problem already exists with code in > > ipa_compute_jump_functions that looks into a callee that might > > change with LTO. > > I either don't understand or fail to see how this is different from > the first problem. We even compute jump functions of indirect edges > precisely because we hope they will be changed later on... Well, it is sort of similar. What is new that same function can be now called in overwritable and non-overwritable way. The old problem is that what used to be overwritable at analysis time is not neccesarily so at WPA time. > > > > Index: ipa-cp.c > > =================================================================== > > --- ipa-cp.c (revision 174905) > > +++ ipa-cp.c (working copy) > > @@ -818,7 +828,7 @@ ipcp_iterate_stage (void) > > /* Some lattices have changed from IPA_TOP to IPA_BOTTOM. > > This change should be propagated. */ > > { > > - gcc_assert (n_cloning_candidates); > > + /*gcc_assert (n_cloning_candidates);*/ > > ipcp_propagate_stage (); > > } > > if (dump_file) > > > I know this assert can be horribly irritating but so far it has been > very useful at spotting all kinds of errors at various places. (In > fact, you added it :-) > > But as I want to get the whole IPA-CP replaced, I don't care all that > much. I am pretty sure I didn't meant to remove it and had the whole thing tested with the assert. The issue was that once aliases are skipped by propagate stage, the lattices stay top. But I already fixed it elsewhere, so I will regtest reverting that hunk. Thanks for pointing this out! Honza > > Martin