This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: optimization/10196: [3.3/3.4 regression] Compile time regressionwith inlining
- From: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- To: gcc-gnats at gcc dot gnu dot org, rguenth at tat dot physik dot uni-tuebingen dot de,gcc-bugs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org
- Date: Tue, 08 Apr 2003 11:51:21 +0200
- Subject: Re: optimization/10196: [3.3/3.4 regression] Compile time regressionwith inlining
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10196
I have tried to compile the test case with a profiling 3.3 (mainline
rejects the code). It didn't quite work...
The profiling information makes it all even slower, and it hogs up
so much memory that the compiler just dies. My profiling compiler
dies after 15 minutes or so. The final announcement is:
int GridPartition<Dim>::partition(const D&,
std::vector<Node<Interval<Dim>, Interval<Dim> >*,
std::allocator<Node<Interval<Dim>, Interval<Dim> >*> >&, const
ContextMapper<Dim>&) const [with D = Interval<1>, int Dim = 1] GC
{197832k -> 53003k}Killed
(box is i586-pc-linux-gnu with 192MB RAM, and >300MB swap)
I don't know what exactly to make of this, but obviously eating so
much memory is *not* good. Also, the biggest contributions to the
compile time apart from expand are cfg-cleanup and jump, so
apparently expand fills memory with lots of garbage left to be
cleaned up by cfg-cleanup and jump. Which is not really news, of
course.
Greetz
Steven