This is the mail archive of the
mailing list for the GCC project.
Re: Memory overhead of tree-SSA optimization passes
- From: Jan Hubicka <jh at suse dot cz>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Jan Hubicka <jh at suse dot cz>, gcc at gcc dot gnu dot org, law at redhat dot com,stevenb at suse dot de
- Date: Sat, 4 Sep 2004 22:41:22 +0200
- Subject: Re: Memory overhead of tree-SSA optimization passes
- References: <20040904132213.GC31593@kam.mff.cuni.cz> <email@example.com>
> 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.