This is the mail archive of the
mailing list for the GCC project.
Re: Bootstrap failures
- From: "Daniel Berlin" <dberlin at dberlin dot org>
- To: "Jan Hubicka" <jh at suse dot cz>
- Cc: "Zdenek Dvorak" <rakdver at atrey dot karlin dot mff dot cuni dot cz>, gcc-patches <gcc-patches at gcc dot gnu dot org>, "Richard Guenther" <rguenther at suse dot de>
- Date: Sat, 21 Oct 2006 08:27:51 -0400
- Subject: Re: Bootstrap failures
- References: <20061020170400.GA2835@atrey.karlin.mff.cuni.cz> <firstname.lastname@example.org> <20061021112227.GA9408@kam.mff.cuni.cz>
looks like your patch further increase memory consumption. Overall
footprint of -O1 insn-attrtab compilation is now 15% up compared to day
This is due to having more vops at store and load sites (basically one
more per load and store and call).
This is because all insn-attrtab does is access global memory, and
call getter funcs so basically every load and store and call is a
touch of the nonlocal vop.
Sadly, *this* vop is hard to avoid, because we were getting incorrect
results before. The type-specific patch usually avoided them by TBAA,
but we aren't doing that anymore. This is just a case where we have
to use an extra vop to be correct in all cases, even though it doesn't
matter in 99% of cases right now.
The only obvious way around this would be to do something similar to
the SMT_USED_ALONE stuff for NONLOCAL, and i really do *not* want to
reimplement that hack for 4.2.
Even though it saved 10% of memory, it ended up being a serious can of worms.
I'll look into this and see if there is any other way to get some low
hanging fruit, but i'm not too hopeful.
You could also turn off all struct aliasing and pruning to fix two of
the PR's, but that doesn't really fix them so much as hide them better
(we'll never be able to eliminate the false aliases that cause the
problem). Fixing 28778 another way would requiring keeping a copy of
the alias lists before they are tbaa pruned, so is also just as peak
memory expensive, but not as gc memory intensive (because you can
obstack these and blow them away if you keep them as bitmaps).
Otherwise, better ideas and patches welcome!
Also note that on a checking enabled compiler, insn-attrtab.i takes
scheduling 2 : 185.76 (63%) usr 1.11 ( 3%) sys 194.83
(55%) wall 1436 kB ( 1%) ggc
on my machine.
What is up with that (this is before my patch)?