From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10894 invoked by alias); 16 Oct 2014 11:50:37 -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 10882 invoked by uid 89); 16 Oct 2014 11:50:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 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; Thu, 16 Oct 2014 11:50:36 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id DCF7354111A; Thu, 16 Oct 2014 13:50:32 +0200 (CEST) Date: Thu, 16 Oct 2014 11:52:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , Martin =?iso-8859-2?Q?Li=B9ka?= , GCC Patches , Martin Jambor Subject: Re: [RFC, PATCH]: Introduction of callgraph annotation class Message-ID: <20141016115032.GB29132@kam.mff.cuni.cz> References: <543EA03A.7000000@suse.cz> <20141016114052.GA11618@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.21 (2010-09-15) X-SW-Source: 2014-10/txt/msg01545.txt.bz2 > On Thu, Oct 16, 2014 at 1:40 PM, Jan Hubicka wrote: > >> > >> I don't like "generic annotation" facilities at all. Would it be possible > > > > Why? > > Because it's the way to hell if the IL has "magic" things only one > pass can understand. It can't ever know if it may invalidate some > of that data. Well, this is mostly indented for maintaining WHOPR summaries where we already have infrastructure to keep them up to date just the APIs are somewhat unhandy (having to register hooks all the time) I also think we can put there sparse stuff that is part of IL but you do not want to allocate it for every symbol/decl or statement (like EH regions or not stuff in symbol table that can not be easily handled by non-multiple inheritance) Honza > > Same reason why I dislike the ->aux pointers we have. (even if they > are of course convenient) > > >> to make cgraph UIDs not sparse? (keep a free-list of cgraph nodes > > > > cgraph nodes are already kept "dense" via freelist. However in WPA you usually have a lot > > of different nodes prior merging and unreachable code removal and very few afterwards, > > the number of nodes grows again with inlining. > > > > Depending on what you want to store for values, I guess either vector or hashtable is > > good choice - if you want to keep data that needs to be duplicated per inline clone > > you can rely on density. If you want data on few function bodies, you will likely use > > hash... > > > > Honza > > > >> with UID < cgraph_max_uid, only really free nodes at the end) > >> Using a different data structure than a vector indexed by cgraph UID > >> should also be easily possible (a map from UID to data, hash_map ). > >> > >> Richard. > >> > >> > Thank you, > >> > Martin