This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Extreme PRE compile times


On Thursday 13 November 2003 17:12, Daniel Berlin wrote:
> On Thu, 13 Nov 2003, Steven Bosscher wrote:
> > On Thursday 13 November 2003 05:42, law@redhat.com wrote:
> > > Clearly PRE is still doing something that's not terribly intelligent
> > > given that PRE + the increase the GC time accounts for 90% of the total
> > > compilation time for this file.
> >
> > What do you expect, with a ggc_collect() call inside a loop?
>
> Which I have to do, because of the amount of garbage we generate (because
> everything in tree-ssa is ggc_alloc'd).

Yeah, it's not your fault, what we now have basically just sucks.

We should have a way to allocate objects in GC space, but where the user 
somehow has more control over what can be allocated/freed.  There are many 
passes that produce obvious garbage and right now we put it right between the 
"non-garbage".  That's just wasteful.

The idea I had to work around this a bit, is to introduce some kind of GC pool 
allocator.  A pass would allocate some memory in GC space, and allocate/free 
objects in that space.  Memory for freed objects could be re-used, just like 
with "real" alloc pools.  The pass would be resposnsible for making sure that 
nothing points at "freed" objects.  At the end of the pass the space would be 
"released" to the garbage collector.
This gives passes some kind of "scratch space", and you'd only have to collect 
at the end of each pass.  And things like fragmentation would be at least no 
worse than what we have now.

(Something like this would also make it easier to make basic blocks & edges 
garbage collectable without losing the nice properties of alloc-pools...)

This all is probably not too hard to implement for the page allocator (dunno 
about ggc-simple/ggc-zone, or what would happen on out-of-memory, or...).  
The thing is, right now it would have to be implemented for _three_ different 
collectors :-(
Does it sound like a reasonable idea at all?

BTW Just how much garbage does PRE produce?

Gr.
Steven


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]