Van Snyder said:
> At some optimization level, do compilers typically duplicate loops
> that examine assumed-shape arrays, to provide the first kind of
> loop above in the case of unit stride, and the second otherwise?
We (NAG) now provide options that tell whether to optimise assumed-shape
arrays for contiguous (i.e. "unit stride") vs. non-contiguous arrays; viz
-Oassumed=section
optimises for array section arguments [default].
-Oassumed=contig
optimises for contiguous arguments.
If the actual argument is not contiguous, a contiguous copy is made
(this is pretty slow, but usually generates much less code than
producing duplicate copies of each loop)
-Oassumed=always_contig
optimises for contiguous arguments.
A runtime error occurs if the actual argument is not contiguous.
Although these options are not exactly what you had in mind, they are an
attempt to address the problem and illustrate that vendors are considering
these issues (I know that other vendors are also looking at various
possibilities here - compiler options, directives, etc.).
> If not, how can I do it, other than by using the above Fortran 77
> idioms?
Note that assumed-shape actually provides slightly more functionality than
the F77 idioms; assumed-shape can handle "fractional" strides, e.g.
TYPE T
DOUBLE PRECISION D
REAL X
END TYPE
TYPE(T) VAR(100)
CALL SUB(VAR%D)
In this case, if a TYPE(T) variable only takes up 12 bytes (i.e. only 4-byte
alignment is imposed on double precision variables), the stride is 1.5 (viz
12/8).
Cheers,
--
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
([log in to unmask])
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|