VECTORIZATION DIRECTIVES

Vectorization is described in section 10. The following directives are used to control it:

• VECTOR

• NOVECTOR

• IVDEP

• VFUNCTION

1.4.1.1 Suppressing vectorization (VECTOR and NOVECTOR)

The NOVECTOR directive suppresses the compiler's attempts to vectorize loops. NOVECTOR takes effect at the beginning of the next loop and applies to the rest of the program unit unless it is superseded by a VECTOR directive.

The VECTOR directive causes the compiler to resume its attempts to vectorize loops if such attempts were suppressed by a previous

vectorization directive. After a VECTOR directive is specified, DO-loops with a known trip count of one are executed in scalar mode; vectorization is attempted for those with a trip count of 4 or more or with an unknown trip count.

The VECTOR vectorized directive.

superseded

directive takes effect immediately; however, a loop is not if any statement in the loop is in the range of a NOVECTOR

VECTOR applies to the rest of the program unit unless it is by another vectorization directive.

The scope of the VECTOR and NOVECTOR directives is a single program unit. VECTOR and NOVECTOR are superseded by the -o/OPT keyword. Both VECTOR and NOVECTOR directives can be specified in a single program unit.

1.4.1.2 Ignore dependencies (IVDEP)

The IVDEP directive, appearing immediately before a loop, causes the compiler to ignore vector dependencies, including explicit dependencies, in any attempts to vectorize the loop. IVDEP applies only to DO loops and affects only the loop it directly precedes. Whether or not IVDEP is used, conditions other than vector dependencies can inhibit

vectorization. IVDEP is superseded by the -o/OPT keyword.

I

1.4.1.3 Vectorizable functions (VFUNCTION)

The VFUNCTION directive declares that a vector version of an external function exists. The VFUNCTION directive must precede any statement function definitions or executable statements in a program.

VFUNCTION f[,f] ...

f Symbolic name of a vector external function; cannot have more than 6 characters. (This is because the ~ character is added at the beginning and end of the name as part of the calling sequence.)

The following rules and recommendations apply to any function f named as an argument in a VFUNCTION directive:

• f must be written in CAL and must use the call-by-register sequence.

• Arguments to f must be either vectorizable expressions or scalar expressions; array expressions are not allowed.

• A call to f can pass a maximum of seven single-word items or three double-word items. These can be mixed in any order with a maximum of seven words total.

• f should receive inputs from its argument list rather than from a common block.

• f should not change the value of its arguments or variables in common blocks. Any changed value should be for variables that are distinct from the arguments.

• f should not reference variables in common blocks that are also used by a program unit in the calling chain.

• f must not have side effects.

If the argument list for f contains both scalar and vector arguments in a vector loop, the scalar arguments are broadcast into the appropriate vector registers. If all arguments are scalar or the function reference is not in a vector loop, f is called with all arguments passed in S registers.

1.4.1.4 Loops with low trip counts (SHORTLOOP)

The SHORTLOOP directive, placed before a DO statement, causes the DO loop to be executed at least once and at most 64 times, allowing CFT77 to generate special code. SHORTLOOP can shorten execution time because i t eliminates the runtime tests that determine whether a vectorized DO loop has been completed. If the DO loop's trip count is outside the range of 1 to 64, results are unpredictable.

1.4.1.5 Register storage across subprograms (NO SIDE EFFECTS)

The NO SIDE EFFECTS directive allows the compiler to keep information in registers across subprogram invocations without reloading the information from memory after returning from the subprogram. The directive is not needed for intrinsic functions and VFUNCTIONS.

NO SIDE EFFECTS declares that a called subprogram does not redefine any variables that are local to the calling program, passed as arguments to the subprogram, or declared in a common block.

f

NO SIDE EFFECTS f[,f] ...

Symbolic name of a subprogram the user guarantees to have no side effects. f must not be the name of a dummy

procedure.

A NO SIDE EFFECTS subprogram should receive inputs from its arguments.

It should not reference or define variables in a common block shared by a program unit in the calling chain, or redefine the value of its

arguments. If these conditions are not met, results are unpredictable.

The NO SIDE EFFECTS directive must precede arithmetic statement functions and executable statements in a program.

CFT77 may move invocations of a NO SIDE EFFECTS subprogram from the body of a DO loop to the loop preample if the arguments to that function are invariant in the loop. This may affect the results of the program, particularly if the NO SIDE EFFECTS subprogram calls functions like the random number generator or the real-time clock.

1.4.2 SCALAR OPTIMIZATION DIRECTIVES

Two directives (SUPPRESS and NOBL) are available to deactivate

optimization to counteract occasional side-effects of register storage and bottom-loading of loop operands.

1.4.2.1 Momentary suppression (SUPPRESS)

The SUPPRESS directive suppresses scalar optimization at the point where the directive appears (and prevents vectorization of any loop that

includes SUPPRESS). At CDIR$ SUPPRESS, variables in registers are stored to memory (to be read out at their next reference), and expressions are recomputed at their next reference after CDIR$ SUPPRESS. The effect on optimization is equivalent to that of a subroutine call whose argument list includes every variable in the calling program unit. Example:

CALL DUMMY (all variables) Sbrtn only returns to calling unit The above statement has the same effect on optimization as SUPPRESS, if subroutine DUMMY does nothing but return to the calling program unit. Optimization guarantees that all variables are stored to memory before the call to DUMMY, because they are in the argument list; and i t guarantees that after the call, at the next reference, each variable must be read from memory and each expression must be recomputed.

Unlike other compiler directives, SUPPRESS takes effect only if i t is on an execution path. That is, optimization proceeds normally if the

directive's path is not executed because of a GOTO or IF. Example:

SUBROUTINE SUB (L) LOGICAL L

A

=

IF (L) THEN CDIR$ SUPPRESS

CALL ROUTINE() ELSE

PRINT *, A ENDIF

END

A is local

SUPPRESS has no effect if L is false

In the PRINT statement above, optimization replaces the reference to A with the constant 1, even though CDIR$ SUPPRESS appears between A=l and the PRINT statement. The IF statement causes execution to bypass CDIR$ SUPPRESS. If SUPPRESS appears before the IF statement, A in PRINT *, A is not replaced by the constant 1.

1.4.2.2 Bottom loading of operands (BL/NOBL)

The NOBL directive disables bottom loading of loops; the BL directive causes the compiler to resume bottom loading. Bottom loading, used only on eligible scalar loops, consists of prefetching operands during each iteration for use in the next iteration.

A prefetch is performed even during the final loop iteration, because the final jump test has not been performed. If the final iteration accesses the first or last address of an array, the final prefetch attempts to access an address outside the array. If the address is outside the user program area, an operand range error can occur. To prevent this problem, use the NOBL directive to turn off bottom-loading. Example:

REAL ARRAY(10) DO 10 1=1,10

Y = X*ARRAY(I) + •••

Operand ARRAY(I+1) is fetched for next iteration 10 CONTINUE

Storage of ARRAY:

ARRAY(1)

ARRAY(10) ~ End of user area

~ Final prefetch attempts to access this address

The scope of the BL and NOBL directives is a single program unit. Either directive applies for the remainder of the program unit or until the appearance of the other directive in the same program unit. Both directives can be specified in a single program unit.