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: Memory overhead of tree-SSA optimization passes


> On Sat, 2004-09-04 at 15:22 +0200, Jan Hubicka wrote:
> > Hi,
> > I've made another little experiment about memory usage.  On combine.c we
> > produce 20MB of garbage for -O0 compilation (compared to 12MB of 3.4),
> > 29MB of garbage with -O2 but all optimizers on tree-ssa disabled (so we
> > only go in and out SSA) and 44MB with default settings.
> > 
> > If you look into individual optimizers, we currently have no optimizer
> > saving memory (except for possibly DCE that cause abort when disabled)
> > major offender are dominators and pre together producing 9.8MB of
> > garbage (roughly 3/4 of the overall overhead)
> > 
> > For PRE we consume most of memory in bitmaps, I am just testing patch
> > obstackeizing them that should actually help here reducing GGC garbage
> > to 40MB but still I don't follow why we need such an extreme amount of
> > bitmaps.
> > 
> Basically, PRE doesn't ever free the sets, it just creates new ones and
> lets GGC take care of freeing the old ones.
> 
> It's something i've been meaning to clean up for a while (we know when
> we can free the old sets, it's just a matter of doing it).
> I can fix it if it's really creating that much garbage.
> However, it never actually showed up as something that mattered in any
> timings i did.

Well, 15% of garbage is quite a lot, but the obstack trick seems to be
good enought (ie we temporarily allocate some 4MB of bitmaps but get rid
of them quickly and cheaply), so I am not sure if any further work on
cleaning them while doing the PRE itself would pay back.

Honza
> 
> --Dan
> 


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