Subprogram Call in a Loop

A subprogram call in a loop (or in any subprograms called from within the called routine) may introduce data dependencies that could go unnoticed without a deep analysis of the data and control flow through the chain of calls. While it is best to parallelize outermost loops that do a significant amount of the work, these tend to be the very loops that involve subprogram calls.

Because such an interprocedural analysis is difficult and could greatly increase compilation time, automatic parallelization modes do not attempt it. With explicit parallelization, the compiler generates parallelized code for a loop marked with a DOALL directive that contains calls to subprograms. It is still the programmer's responsibility toeinsure that no data dependencies exist within the loop and all that the loop encloses, including called subprograms.

Multiple invocations of a routine from different processors can cause problems resulting from references to local static variables that interfere with each other. Making all the local variables in a routine automatic rather than static prevents this. Each invocation of a subprogram then has its own unique store of local variables maintained on the stack, and no two invocations will interfere with each other.

Local subprogram variables can be made automatic variables that reside on the stack either by listing them on an AUTOMATIC statement or by compiling the subprogram with the -stackvar option. However, local variables initialized in DATA statements must be rewritten to be initialized in actual assignments.

Allocating local variables to the stack can cause stack overflow. See "Stacks, Stack Sizes, and Parallelization" about increasing the size of the stack.

Data dependencies can still be introduced through the data passed down the call tree as arguments or through COMMON blocks. This data flow should be analyzed carefully before parallelizing a loop with subprogram calls.