Re: [PATCH 3/5] IPA ICF pass

[Jan Hubicka <hubicka@ucw.cz>]

> >
> >35% means that 35% of all function bodies are compared with something else? That feels pretty high.
> >but overall numbers are not so terrible.
> 
> Currently, the pass is able to merge 32K functions. As you know, we group functions to so called classes.
> According to stats, average non-singular class size contains at the end of comparison 7.39 candidates and we
> have 5K such functions. Because we load body for each candidate in such groups, it gives us minimum number
> of loaded bodies: 37K. As we load 70K function, we have still place to improve. But I guess WPA body-less
> comparison is quite efficient.

OK, that seems resonable.
> 
> >
> >>with speed was hidden in work list for congruence classes, where hash_set was used. I chose the data
> >>structure to support delete operation, but it was really slow. Thus, hash_set was replaced with linked list
> >>and a flag is used to identify if a set is removed or not.
> >
> >Interesting, I would not expect bottleneck in a congruence solving :)
> 
> The problem was just the hash_set that showed to be slow data structure for a set of operations needed
> in congruence solving.
> 
> >>
> >>I have no clue who complicated can it be to implement release_body function to an operation that
> >>really releases the memory?
> >
> >I suppose one can keep the caches from streamer and free trees read.  Freeing
> >gimple statemnts, cfg should be relatively easy.
> >
> >Lets however first try to tune the implementation rather than try to this hack
> >implemented. Explicit ggc_free calls traditionally tended to cause some negative
> >reactions wrt memory fragmentation concerns.
> 
> Agree with suggested approach.

In future we actually may keep the duplicated functions in WPA memory and use corresponding body
whenever the function is inlined to avoid disturbing debug info more than needed.

Honza
> 
> >
> >>
> >>Markus' problem with -fprofile-use has been removed, IPA-ICF is preceding devirtualization pass. I hope it is fine?
> >
> >Yes, I think devirtualization should actually work better with identical
> >virutal methods merged.  We just need to be sure it sees through the newly
> >introduced aliases (there should be no thunks for virutal methods)
> 
> Thanks,
> Martin
> 
> >
> >Honza
> >