From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64851 invoked by alias); 29 Sep 2017 19:28:09 -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 62709 invoked by uid 89); 29 Sep 2017 19:28:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=anticipation, associate, Hx-languages-length:1442, forth 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 ESMTP; Fri, 29 Sep 2017 19:28:06 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 312595488AA; Fri, 29 Sep 2017 21:28:04 +0200 (CEST) Date: Fri, 29 Sep 2017 19:28:00 -0000 From: Jan Hubicka To: Prathamesh Kulkarni Cc: gcc Patches , Richard Biener Subject: Re: [RFC] propagate malloc attribute in ipa-pure-const pass Message-ID: <20170929192803.GA92290@kam.mff.cuni.cz> References: <20170519133212.GB36419@kam.mff.cuni.cz> <20170926002423.GB22198@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2017-09/txt/msg01990.txt.bz2 > > I wonder what happens here when, say, ipa-icf redirect the call to eqivaelnt > > function and removes the callee? Perhaps we realy want to have set of call > > sites rahter than nodes stored from analysis to execution. Call sites have > > unique stmts and uids, so it will be possible to map them back and forth. > IIUC, call site is represented using cgraph_edge ? Yes, there is call_stmt pointer when gimple is read and uid in WPA mode which are unique. There is call_summary class which lets you to associate info with a call site. While it is not most memory effecient to store one bit of information this way, i guess it may be easiest to use it in anticipation of it becoming more useful in foreseeable future. We have some bits in call edge itself that may be shuffled to the summary as well. > So change return_callees_map to be the mapping from node to subset of > it's call-sites where > node returns the value of one of it's callees: > static hash_map< cgraph_node *, vec *> *return_callees_map; ? This should work too, though storing direct pointers to edges is something we probably want to avoid to keep memory representation of edges in bounds. I would go with call_summary - everything else seems like bit of premature optimization. If we will decide to optimize it later, we may invent a variant of summary datatype for that. Thanks, Honza