Re: A recent patch increased GCC's memory consumption!

[Richard Guenther <rguenther at suse dot de>]

On Thu, 28 Feb 2008, Jan Hubicka wrote:

> > On Thu, 28 Feb 2008, Jan Hubicka wrote:
> > 
> > > > On Thu, 28 Feb 2008, Jan Hubicka wrote:
> > > > 
> > > > > Hi,
> > > > > memory tester didn't run for a while but I do believe this memory usage
> > > > > growth is yours.  Looks like is_marked_p hack does not work somehow?
> > > > 
> > > > It should..., but as the patch seems to cause bootstrap failure on i686
> > > > I am going to revert it again anyway.  I have no time investigating all
> > > > this mess.
> > > 
> > > It would be shame to give it up completely.  Is the i686 breakage also
> > > ggc_free related?  I can try to help here.
> > > Reverting will definitly tell us if the memory usage goes back however.
> > 
> > No idea, it is a bootstrap comparison failure, so I'd guess a GC 
> > dependency during referenced vars walk.
> 
> I see.  Clearly with with the is_marked_p we have dependency here, since
> removing stuff from hashtable triggers different resizing that triggers
> different ordering.  Can't we live without the walk?

Nono, we made refernced vars a bitmap, so it is _not_ dependent on
GC, but is strictly UID ordered with the patch.  We don't walk the global
table.  But what can happen is that the strictly odered UID walk comes
along a dead DECL and thus the amount of decls visited is dependend on
GC (not their order).  But of course the decl would be dead anyway, with
or without GC -- so scheduling remove_unused_vars properly or not doing
things dependent on dead decls would fix this.

But as said -- another time.

Richard.