Suggested addition to documentation

[lucier at math dot purdue dot edu]

At the end of this message is a note I posted to comp.arch in
response to Bernd Payson's claim that gcc-3.0 has optimization bugs
because gforth runs much more slowly when compiled with gcc-3.0 than
when compiled with gcc-2.95.2.  So, again, I suggest that the
documentation be augmented with the following warning, which is a diff
against invoke.texi in gcc-3.0 release.

texas-253% rcsdiff -cp invoke.texi
===================================================================
RCS file: RCS/invoke.texi,v
retrieving revision 1.1
diff -cp -r1.1 invoke.texi
*** invoke.texi 2001/06/29 13:10:35     1.1
--- invoke.texi 2001/06/29 13:15:35
*************** function inlining, and register renaming
*** 3154,3159 ****
--- 3154,3162 ----
  @option{-fforce-mem} option on all machines and frame pointer elimination
  on machines where doing so does not interfere with debugging.
  
+ Please note the warning under @option{-fgcse} about invoking @option{-O2}
+ on programs that use computed gotos.
+ 
  @item -O3
  @opindex O3
  Optimize yet more.  @option{-O3} turns on all optimizations specified by
*************** Run the loop optimizer twice.
*** 3398,3403 ****
--- 3401,3411 ----
  @opindex fgcse
  Perform a global common subexpression elimination pass.
  This pass also performs global constant and copy propagation.
+ 
+ @emph{Note:} When you compile a program using computed gotos, a GCC extension,
+ you may get better runtime performance if you disable the global common
+ subexpression elmination pass by adding @option{-fno-gcse}
+ to the command line.
  
  @item -fdelete-null-pointer-checks
  @opindex fdelete-null-pointer-checks

Brad

Path: purdue!not-for-mail
From: bjl@cs.purdue.edu (Bradley J Lucier)
Newsgroups: comp.arch
Subject: GCC-3.0 and Gforth (was Re: Compilers and IA-64.)
Date: 29 Jun 2001 08:16:33 -0500
Organization: Purdue University, West Lafayette, IN.
Lines: 46
Message-ID: <9hhv3h$c71@arthur.cs.purdue.edu>
References: <3B38F729.F6729995@moene.indiv.nluug.nl> <ur9k81xilgn.fsf@vino.ics.uci.edu> <3B3BB25E.4D8211DA@spamcop.net> <3B3CCAED.B8C4767B@mikron.de>
NNTP-Posting-Host: arthur.cs.purdue.edu
Cc: bjl@cs.purdue.edu

Bernd Payson wrote:
> David Keaton wrote:
> > >        The difference for GCC runtime (from SPEC) was close to 10-15%,
> > >        without profiling feedback."
> > >
> > > It seems to say that the old technology GCC is not that bad when
> > > compared with all the other compiler. Which sounds aaahh... odd, taking
> > > into account that GCC does not implement yet a lot of the fancy
> > > optimizations.
> > 
> >      Good point.  It's important to keep it all in perspective.  In
> > compilers, a "huge" improvement is often 5%, or more likely 1% in the
> > general case and 20% on a particular loop kernel that happens to be
> > important to a benchmark.
> 
> >From the first look at GCC 3.0, it does look that there are still lots
> of optimization bugs lurking in there, at least for x86 (that's what
> I've seen, e.g. Gforth on GCC 3.0 is 1.5-2.5 times slower on Athlon than
> GCC 2.95.3). The x86 frontend is renewed, and the optimizations added
> seem to cause troubles, too.

Many threaded interpreters (Forth, JVM, bytecode interpreters of all sorts)
run more slowly when compiled with gcc-3.0 and gcse (which is invoked
by default with -O2).  Here's why.

Many such interpreters are coded as finite state machines with transitions
implemented using computed gotos, a gcc extension to C.  With gcc-2.95.2
(and likely with gcc-2.95.3, I haven't checked), the gcse pass did not
properly do Lazy Code Motion (LCM) over non-splitable edges, which are
generated by computed goto's.  So, gcc-2.95.2 could generate incorrect code
for these programs.

This was recognized for 3.0 development, and fixed by declaring that
all global variables are killed at the beginning of blocks that are
the target of at least one computed goto.  I say fixed, in that the
generated code is now correct, but gcc-3.0 can generate much slower code
for a program that relies extensively on computed gotos.

So I suggest you try using -O2 -fno-gcse for programs that use
computed gotos; perhaps this will help Gforth.

I suggested that this anomalous performance behavior be documented
somewhere in the gcc-3.0 documentation, but this was not added before
release.

Brad Lucier