From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29656 invoked by alias); 3 May 2011 16:52:42 -0000 Received: (qmail 29629 invoked by uid 22791); 3 May 2011 16:52:38 -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; Tue, 03 May 2011 16:52:20 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id B15819AC83D; Tue, 3 May 2011 18:52:19 +0200 (CEST) Date: Tue, 03 May 2011 16:52:00 -0000 From: Jan Hubicka To: Richard Guenther Cc: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: Move cgraph_node_set and varpool_node_set out of GGC and make them use pointer_map Message-ID: <20110503165219.GC18705@kam.mff.cuni.cz> References: <20110503153337.GA18705@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.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-05/txt/msg00198.txt.bz2 > > We have both a vector and a pointer-map. Why not simply use a > pointer-map only?! I see this may need more re-structuring, eventually Well, pointer-maps would be randomly ordered (sensitive to pointer values) and thus we would give different .o files depending on memory layout. But yes, combination of hashtable and array is bit funny. I was considering using simple bitmaps but given that the sets might be large and we do quite many queries, I concluded that it might lead to problems with O(n) lookup times in our bitmap structure. The problem of frequent lookups is actually problem with fact that ipa-reference output routines are quadratic in computing the boundary. Something I will fix later, too. Still replacing htab here seems like obvious improvement. pointer-map looks even prettier and it should be good enough for any future use we can come up in WHOPR. Unlike the type merging and streamer cache, those sets are relatively small. > adding an iterator interface to pointer-sets/maps (which would be > nice anyway). > > It also makes me think again that why do we have both a cgraph > and a varpool set ... at least when you now deal with a non-GC > data structure you could as well use a vector of void * and > provide macros doing the casting for you, unifying the implementation > itself. I would deffer this to symtab patches that will unify both sets into single structure. > > Well, I suppose most of that can be done as a followup (when > eventually the symtab arrives and varpool and cgraph nodes merge anyway). > > Thus, ok for now. Thanks! Honza > > Thanks, > Richard.