From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105200 invoked by alias); 30 Mar 2015 17:05:41 -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 105181 invoked by uid 89); 30 Mar 2015 17:05:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 30 Mar 2015 17:05:40 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 904F3547147; Mon, 30 Mar 2015 19:05:37 +0200 (CEST) Date: Mon, 30 Mar 2015 17:05:00 -0000 From: Jan Hubicka To: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: ipa-cp heuristic tweek Message-ID: <20150330170537.GC93920@kam.mff.cuni.cz> References: <20150329154320.GA67588@kam.mff.cuni.cz> <20150330121114.GF2305@virgil.suse> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150330121114.GF2305@virgil.suse> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-03/txt/msg01565.txt.bz2 > > Index: ipa-cp.c > > =================================================================== > > --- ipa-cp.c (revision 221757) > > +++ ipa-cp.c (working copy) > > @@ -811,6 +811,41 @@ set_all_contains_variable (struct ipcp_p > > return ret; > > } > > > > +/* Worker of call_for_symbol_thunks_and_aliases, increment the integer DATA > > + points to by the number of callers to NODE. */ > > + > > +static bool > > +count_callers (cgraph_node *node, void *data) > > +{ > > + int *caller_count = (int *) data; > > + > > + for (cgraph_edge *cs = node->callers; cs; cs = cs->next_caller) > > + /* Local thunks can be handled transparently, but if the thunk can not > > + be optimized out, count it as a real use. */ > > + if (!cs->caller->thunk.thunk_p || !cs->caller->local.local) > > + ++*caller_count; > > ...we don't recurse for local thunks and do not count their number of > callers here. I'm not sure if it can ever happen in practice but if > we have a local function that is called multiple times but always > through one particular local thunk, we should end with caller_count > greater than one, and with this code we will not? Such function > certainly should not be considered called just once by the inliner. Inliner won't inline to thunks at all currently, but you call the function by for_symbol_thunks_and_aliases, so the recursion to thunks already happens by this wrapper. > > Similarly, if we ever have a local node with a non-local thunk (would > that be legal and make sense?), then we should try not ending up with We currently keep local falg in sync in between thunks and functions (otherwise i386 calling convetions will break). But indeed we may add check here to avoid dependency on this detail. Honza > caller_count == 1, because inliner will also never consider that > function just called once. So I'd suggest incrementing the caller by > two instead in that case. > > But maybe I just don't understand what "handled transparently" in the > comment means. > > Thanks for clearing this up, > > Martin