optimization/10196: [3.3/3.4 regression] Compile time regression with inlining
Steven Bosscher
s.bosscher@student.tudelft.nl
Tue Apr 8 09:56:00 GMT 2003
The following reply was made to PR optimization/10196; it has been noted by GNATS.
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, rguenth@tat.physik.uni-tuebingen.de,
gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org
Cc:
Subject: Re: optimization/10196: [3.3/3.4 regression] Compile time regression
with inlining
Date: Tue, 08 Apr 2003 11:51:21 +0200
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
More information about the Gcc-prs
mailing list