> > 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.
