20.2 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.)