Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!batman!fred
From: fred@mips.COM (Fred Chow)
Newsgroups: comp.sys.dec
Subject: Re: When is -O2 faster than -O3 for MIPS compiler?
Keywords: MIPS, optimization, compiler
Message-ID: <44435@mips.mips.COM>
Date: 2 Jan 91 21:20:50 GMT
References: <765@nvuxl.UUCP>
Sender: news@mips.COM
Reply-To: fred@mips.COM (Fred Chow)
Organization: Your Organization Goes Here
Lines: 59

In article <765@nvuxl.UUCP> hsong@nvuxl.UUCP (g hugh song) writes:
>
>I wrote yesterday about the f77 compiler 2.1 for DecStation 5000/200
>with Ultrix 4.0 :
>> It is running with -O2 -C.  However it does not run without -C.  Usually
>> the revese is the usual case. 
>
>("-C" is for the run-time subscript range checking, BTW)
>I finally pinpointed out a routine which is affected by the compiler
>bug.   (It was not easy to pinpoint out just one routine among
>about 100 routines.)
>
>The same program ran with -O3 without -C, but at slower speed.
>What?  Yes. it ran more than two times slowly with higher optimization 
>level. The other compiler switches I used for both cases are 
>"-Olimit 2000 -align32" and either "-c" or "-j" with respect to 
>-O2 or -O3.  And the loader switch is "-G 4800".
>
>So my question is:
>In what situation, is "-O2" faster than "-O3"?

From your description, it seems that you compiled your program in the
following two modes:

(1) -O2 -C -Olimit 2000 -align32

(2) -O3 -Olimit 2000 -align32

And you said the program compiled under (2) is twice as slow.  This is
totally impossible, unless your program runs differently and produces
different results.  Compilation with -C will introduce a lot of extra
code to do bounds-checking, and thus will slow down your program.
Sometimes, it can be bugs in the program itself that shows up only
in -O2 and not in -O3 or vice versa, and this may have to do with
uninitialized variables, but there can be other reasons. That fact 
that your program has run on other machines does not give you 100% 
guarantee, because different compiler generates different code. With 
MIPS' compiler, compiling with the -trapuv option will help you 
detect uninitialized variables. If it is a compiler bug, the -C 
option can also cause the compiler bug to disappear. By the way, have 
you tried -g without -O2/-O3/-C and see if the program runs? 

The speed difference between -O2 and -O3 is not great, and usually less
than 20%.  In many programs, -O2 and -O3 yields approximately the
same speed.  Occasionally, there are programs where -O3 is slower than -O2,
but never more than 10%.   

The -align32 option will also slow down your program, because it makes
the compiler issues 2 instructions to load and store doubles in many
memory references.

- Fred Chow (fred@mips.com)

>My conclusion so far is there is a very critical bug in the 
>compiler-optimizer.  And there is no handy mechanism for detecting
>floating point errors.   Someone pointed out "fpc" in <mips/fpu.h>.
>But I still do not understand how it works.
>If you know how to use it, please let us know how to use it.
>