compile time regression, when adding cerr usage

compile time regression, when adding cerr usage

[andre maute]

[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]

when compiling the attached test file, you can see that the debugging test
needs 
	8 min!  with g++-3.4.1
Every other test including g++-3.3.3 needs only some seconds.

Defining __DEBUGGING__ 
enables the usage of std::cerr, which happens at the end of the attached file.

My system is a Dual Pentium III 550 with linux-2.4.26

Regards Andre


--------------- BEGINNING OF TESTS THE -------------------------

login:~ # /opt/gcc-3.3.3/bin/g++-3.3.3 -v
Reading specs from /opt/gcc-3.3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs
Configured with: ../gcc-3.3.3/configure --prefix=/opt/gcc-3.3.3 
--enable-shared --enable-languages=c,c++ --enable-threads=posix 
--enable-__cxa_atexit --enable-clocale=gnu --program-suffix=-3.3.3 
--with-cpu=pentium3
Thread model: posix
gcc version 3.3.3


login:~ # time /opt/gcc-3.3.3/bin/g++-3.3.3 compiletimetest.cc -c -O3 
-funroll-all-loops -frerun-loop-opt -fomit-frame-pointer

real    0m2.202s
user    0m2.150s
sys     0m0.030s


login:~ # time /opt/gcc-3.3.3/bin/g++-3.3.3 compiletimetest.cc -c -O3 
-funroll-all-loops -frerun-loop-opt -fomit-frame-pointer -D __DEBUGGING__

real    0m5.202s
user    0m4.390s
sys     0m0.120s


login:~ # /opt/gcc-3.4.1/bin/g++-3.4.1 -v
Reading specs from /opt/gcc-3.4.1/lib/gcc/i686-pc-linux-gnu/3.4.1/specs
Configured with: ../gcc-3.4.1/configure --prefix=/opt/gcc-3.4.1 
--enable-shared --enable-languages=c,c++ --enable-threads=posix 
--enable-__cxa_atexit --enable-clocale=gnu --program-suffix=-3.4.1 
--with-cpu=pentium3
Thread model: posix
gcc version 3.4.1


login:~ # time /opt/gcc-3.4.1/bin/g++-3.4.1 compiletimetest.cc -c -O3 
-funroll-all-loops -frerun-loop-opt -fomit-frame-pointer

real    0m6.670s
user    0m6.550s
sys     0m0.120s


login:~ # time /opt/gcc-3.4.1/bin/g++-3.4.1 compiletimetest.cc -c -O3 
-funroll-all-loops -frerun-loop-opt -fomit-frame-pointer -D __DEBUGGING__

real    8m31.470s
user    7m53.460s
sys     0m34.400s


[-- Attachment #2: compiletimetest.cc.gz --]
[-- Type: application/x-gzip, Size: 13601 bytes --]

Re: compile time regression, when adding cerr usage

[James E Wilson]

andre maute wrote:
> when compiling the attached test file, you can see that the debugging test
> needs 
> 	8 min!  with g++-3.4.1
> Every other test including g++-3.3.3 needs only some seconds.

We don't track bug reports sent to the gcc-bugs mailing list.  If you 
want something done about this, you should file a bug report into our 
bugzilla bug database.

I took a quick look at this.  You are using -O3 which enables 
-finline-functions.  The presense of the iostreams code causes gcc to 
make different decisions about function inlining and optimization, and 
the code size blows up.  The .s file is almost 7 times as big when the 
debugging code is included.  So the file takes so much longer to compile 
just because there is so much more code.

Part of the issue here might be that the debugging code is confusing the 
gcc optimizer.  It occurs between where the arrays are declared and 
where they are used.  Maybe there is an aliasing problem, or something, 
that is causing some optimization to be missed, that ordinarily would 
prevent the code size from blowing up.  I didn't bother looking into 
this though.  All I did was reproduce the problem.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: compile time regression, when adding cerr usage

[andre maute]

On Tuesday 27 July 2004 02:57, you wrote:
> andre maute wrote:
> > when compiling the attached test file, you can see that the debugging
> > test needs
> > 	8 min!  with g++-3.4.1
> > Every other test including g++-3.3.3 needs only some seconds.
>
> We don't track bug reports sent to the gcc-bugs mailing list.  If you
> want something done about this, you should file a bug report into our
> bugzilla bug database.

i already did that, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16613

>
> I took a quick look at this.  You are using -O3 which enables
> -finline-functions.  The presense of the iostreams code causes gcc to

-fininline-functions is enabled in -O3 for both gcc-3.3.3 and gcc-3.4.1

> make different decisions about function inlining and optimization, and
> the code size blows up.  The .s file is almost 7 times as big when the
> debugging code is included.  So the file takes so much longer to compile
> just because there is so much more code.
but not with gcc-3.3.3

> Part of the issue here might be that the debugging code is confusing the
> gcc optimizer.  It occurs between where the arrays are declared and
> where they are used.
Sorry that's wrong, cerr is declared at the beginning of the file and used at 
the end of the file.

> Maybe there is an aliasing problem, or something, 
> that is causing some optimization to be missed, that ordinarily would
> prevent the code size from blowing up.  I didn't bother looking into
> this though.  All I did was reproduce the problem.

Regards
Andre Maute

Re: compile time regression, when adding cerr usage

[James E Wilson]

andre maute wrote:
> i already did that, see
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16613

Thanks.  I forgot to check for that.  I will add the info I have to the 
bug report.

> -fininline-functions is enabled in -O3 for both gcc-3.3.3 and gcc-3.4.1

Yes, but there are some differences in implementation, and somehow this 
is causing a problem in gcc-3.4.1.

> but not with gcc-3.3.3

I know, you already said that.

> Sorry that's wrong, cerr is declared at the beginning of the file and used at 
> the end of the file.

I meant in the average_n functions, cerr is used in between where the 
variable "a" is declared and when it is used.  However, on further 
review, this turns out not to matter.  It doesn't matter where the cerr 
uses are, only that they exist in  the average_n functions.

If you ifdef out the code that writes to cerr, or stop using 
-finline-functions, the problem goes away.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

[Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage

[andre maute]

[-- Attachment #1: Type: text/plain, Size: 132 bytes --]

Once more i couldn't upload an attachment
with the bugzilla upload form, so i send it here.

I'll refer to it later.

Regards Andre

[-- Attachment #2: compiletimetest2.cc.gz --]
[-- Type: application/x-gzip, Size: 6722 bytes --]

Re: [Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage

[Daniel Berlin]

On Fri, 10 Dec 2004, andre maute wrote:

> Once more i couldn't upload an attachment
> with the bugzilla upload form, so i send it here.
>
You can email it to gcc-bugzilla@gcc.gnu.org with a subject of "Bug 16613" 
(or whatever the bug number is), and it'll auto-add it to the bug for you.