This is the mail archive of the
mailing list for the GCC project.
Re: getting rid of ggc_push_context (was Re: Cleanup tree_rest_of_compilation interface)
> Jan Hubicka wrote:
> >I wonder how desirable is to get rid of ggc_push_context/ggc_pop_context
> >machinery. It should not be terribly dificult deal to make cse.c ggc
> >safe but without using ggc_free that would bring other expenses.
> >What GGC guys prefer?
> I would like to see ggc_push_context go away.
Me too ;) I was looking into that yesterday and even after elliminating
all the calls it seems to be nontrivial to get the machinery out of
ggc-page as it is kind of used for PCH to prevent PCH data from being
collected and dirtified. So it would be nice if someone more familiar
with the code beated me in this...
> >Perhaps it might be possible to trottle the cse memory consumption too.
> >Does someone recall why this call has been added?
> Clearly, because CSE generated a lot of garbage. I think that this
> might have come from uses of the aliasing machinery which generated new
> RTL constantly. In the abstract, there's no reason why CSE should be
> generating lots of garbage in GC'd memory; it should only be generating
> memory for (a) its hash tables, and (b) the new instructions it builds.
My understanding is that the CSE degenerated on the particular plumhall
testcase by walking too many paths, so it consumes a lot of time and
produces considerable garbage at same time.
CSE has already some caching for canonical forms of the RTLs that works
resonably well in the common cases.
But as disucssed on other thread, the push/pop context is not needed
here at all - CSE is ggc safe at path boundary as it flush all the
> Mark Mitchell
> CodeSourcery, LLC
> (916) 791-8304