g77.info: Better Optimization
Go forward to Simplify Porting
Go backward to Efficiency
Go up to Projects
Go to the top op g77
Better Optimization
Much of this work should be put off until after `g77' has all the
features necessary for its widespread acceptance as a useful F77
compiler. However, perhaps this work can be done in parallel during
the feature-adding work.
* Do the equivalent of the trick of putting `extern inline' in front
of every function definition in `libg2c' and #include'ing the
resulting file in `f2c'+`gcc'--that is, inline all
run-time-library functions that are at all worth inlining. (Some
of this has already been done, such as for integral
exponentiation.)
* When doing `CHAR_VAR = CHAR_FUNC(...)', and it's clear that types
line up and `CHAR_VAR' is addressable or not a `VAR_DECL', make
`CHAR_VAR', not a temporary, be the receiver for `CHAR_FUNC'.
(This is now done for `COMPLEX' variables.)
* Design and implement Fortran-specific optimizations that don't
really belong in the back end, or where the front end needs to
give the back end more info than it currently does.
* Design and implement a new run-time library interface, with the
code going into `libgcc' so no special linking is required to link
Fortran programs using standard language features. This library
would speed up lots of things, from I/O (using precompiled formats,
doing just one, or, at most, very few, calls for arrays or array
sections, and so on) to general computing (array/section
implementations of various intrinsics, implementation of commonly
performed loops that aren't likely to be optimally compiled
otherwise, etc.).
Among the important things the library would do are:
* Be a one-stop-shop-type library, hence shareable and usable
by all, in that what are now library-build-time options in
`libg2c' would be moved at least to the `g77' compile phase,
if not to finer grains (such as choosing how list-directed
I/O formatting is done by default at `OPEN' time, for
preconnected units via options or even statements in the main
program unit, maybe even on a per-I/O basis with appropriate
pragma-like devices).
* Probably requiring the new library design, change interface to
normally have `COMPLEX' functions return their values in the way
`gcc' would if they were declared `__complex__ float', rather than
using the mechanism currently used by `CHARACTER' functions
(whereby the functions are compiled as returning void and their
first arg is a pointer to where to store the result). (Don't
append underscores to external names for `COMPLEX' functions in
some cases once `g77' uses `gcc' rather than `f2c' calling
conventions.)
* Do something useful with `doiter' references where possible. For
example, `CALL FOO(I)' cannot modify `I' if within a `DO' loop
that uses `I' as the iteration variable, and the back end might
find that info useful in determining whether it needs to read `I'
back into a register after the call. (It normally has to do that,
unless it knows `FOO' never modifies its passed-by-reference
argument, which is rarely the case for Fortran-77 code.)
Created Mon Nov 8 17:42:20 2004 on tillpc with info_to_html version 0.9.6.