Optimization options in Irix 3.3 Fortran and C

[Bron Campbell Nelson]

In article <1990Sep26.185742.7454 at portia.Stanford.EDU>, dhinds at portia.stanford.edu (David Hinds) writes:
> On the last page of the 3.3 fortran-77 release notes, there is a paragraph
> about optimization of multiprocessed fortran code.  It says the combination
> of -o3 and -mp will disable the "no parameter aliasing" optimization, but
> that this can be re-enabled as an option to "uopt".  My first question is,
> why is this?  What is special about multiprocessed fortran that changes the
> way parameter aliasing can be handled?  (Aliasing is not allowed in the
> Fortran standard, anyway).

The answer is kinda involved, so most readers might prefer to skip down to
the next question, which is more interesting.

This is due to a long standing (bad) design design decision.  The object
file produced by a compiler does identify the language that it came from.
For various reasons I won't go into, MP Fortran is identified as a different
language from ordinary Fortran.  In fact, it turned out to be extremely
expedient to label it as Pascal!  In order to get the standard Fortran
optimizations with something that "looks like" Pascal, the "-noPalias" flag
is passed to the optimizer.

All this works great at -O2.  But at -O3 there is a problem: the optimizer
can do inline expansion, and the -noPalias flag will allow optimizations that
may not be safe if the expanded routine(s) are written in a language that
permits aliasing.  This is admitedly *extremely* rare, but a compiler must
do only safe things (at least, by default).  If your program is written
completely in Fortran, or the non-Fortran parts do not use aliasing, then
you're safe and can turn on the -noPalias optimization at -O3.

It is worth noting by the way that the typical speed up is not too great.
One person I exchanged email with about this topic saw about a 2.5% speedup
on their code by using -noPalias.  Of course, your mileage will vary.
The main reason is that many Fortran codes pass their data around in
COMMON blocks, and the optimizer can already tell that those are not aliased.




> My second question is, is this optimization flag available for code in other
> languages?  Can I link a pure C program with a "-Wo,-noPalias" option if
> my code does not use aliasing, or does the standard library use aliasing
> that will screw things up?  Because aliasing in C is a significant barrier
> to optimization, yet rarely used, it seems that this would be a useful
> trick.

Yes, you should be able to pass the -noPalias flag to uopt from any language.
The inlining that uopt does is done on the compiler intermediate language
(ucode), not on a fully compiled object file. If you link with the standard
libraries (e.g. libc.a or libc_s.a etc.) you should have no problems with
the library code.

I'm not positive how absolute the -noPalias is.  I *think* that it only
holds for the arguments themselves.  Pointers (and especially pointers
to pointers) may still have the conservative "possibly aliased" assumption
applied.

Also and especially: PLEASE NOTE that I'm not going to guarentee that this
will continue to work in the future.  We stuck in this hack to get around
the stupid -O3 MP Fortran problem above.  Some better solution will probably
be done later.

If anyone tries using this, I'd appreciate getting some email mentioning if
it was worth anything.



>         Are there any other options to "uopt" that we should know about?
> I can't find a manual page for it anywhere.

Not that I know of.  Uopt is not really intended to be under direct
user control (hence, no man page).  The -noPalias flag exists only as a
special hack.


--
Bron Campbell Nelson
bron at sgi.com  or possibly  ..!ames!sgi!bron
These statements are my own, not those of Silicon Graphics.