Re: optimization/10196: [3.3/3.4 regression] Compile time regression with inlining

[Steven Bosscher <s.bosscher@student.tudelft.nl>]

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