[Patch, Fortran, F08] PR 55207: Variables declared in the main program should implicitly get the SAVE attribute

Tobias Burnus burnus@net-b.de
Sun Mar 16 18:44:00 GMT 2014


Hi Janus,

Janus Weil wrote:
>> (2) The execution time of fatigue.f90 with the patch at
>> http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00754.html
>> double from 208588 to 208590 unless I use -fstd=f2003.
> Ouch. Double, really? Probably some kind of optimization is not
> possible any more with SAVE (?)

Dominique gave the following numbers (change from r208588 to r208590): 
~1.4s to ~2.9s.

I regard this as bug (missed-optimization) of the middle end. By itself, 
*local* static variables are as well optimizable as stack/heap allocated 
variables. One just needs to be careful when the address can escape.

In terms of optimization, I think the problem mainly occurs when one has 
nested functions. Within the function itself, the compiler can follow 
the control flow. However, when it sees a static variable, which is 
pulled in from elsewhere (e.g. the parent function or a true global 
variable), it essentially stops the analysis.

I think the current behaviour is fine for C/C++, where one cannot have 
nested functions. For Fortran, it is a true missed optimization. 
However, most code does not use many local SAVEd variables together with 
nested functions. - The only big exception are Fortran main programs, 
where the internal functions are common and can become very large.

The question is how to handle this properly. I think we should discuss 
this with ME experts. I think one possibility would be to simply ignore 
the SAVE attribute (implied and explicit) in Fortran main programs for 
scalar numeric variables. I think those are most affected by your patch 
(like: "integer nsize; nsize = ..."), when they are used in internal 
functions. For arrays or larger derived types, one trades the 
possibility for better analysis for a larger stack size. And the stack 
size can small - especially on Windows. Additionally, the ME does in 
general a purer job for arrays (for obvious reasons), hence, the 
disadvantage should be low.

NOTE: With -fcoarray=lib, coarrays in the main program have to retain 
their status as they are allocated/registered before the main program is 
started (constructor). An alternative would be to register them at the 
beginning of the main program - and to move the SYNC ALL from "main" 
into "MAIN__".

Tobias



More information about the Fortran mailing list