Aleksandar Donev wrote:
On Thursday 22 January 2009 10:59, Bill Long wrote:
Only for statements that might involve references or definitions of a volatile variable. The rest of the code can be optimized normally. Which is exactly what we need here.
No. Take:
! complex calculations using array to calculate values: call mpi_isend(array,...) ... ! array not modified here call mpi_wait(...) ! more calculations involving array reading the values
Surely it is ok, desirable, or even necessary to optimize the calculations???
This example shows the problem well. There is no way for the compiler to tell that the mpi_wait call is related to the isend that is using array as its buffer. It might be for a different isend (and hence different buffer) started somewhere else. The only safe thing for the compiler to do is treat array as volatile throughout the subprogram containing these two calls. Which is just what happens if array is declared volatile. It's irrelevant whether you spell the attribute asynchronous or volatile. The effect is the same.
ASYNCHRONOUS only disables code motion accross waits and certain argument associations (such as more care with copy in/out). The rest of the code can be optimized as usual.
If that's the case, then there is a serious problem with ASYNCHRONOUS
But these are covered by the "disables...certain argument associations" part of my sentence. In particular, depending on whether the actual/dummy are (both) asynchronous, some transformations (e.g., copy in/out for the hell of it, copy in/out of more than the piece of the actual, code motion accross the argument call, etc.) should be disabled.
Reread Nick's earlier message. The optimization pitfalls extend past just argument passing.
I understand no compiler actually implements asynchronous so no implementor has actually pinned down the list of what optimizations are "not allowed",
I'm sure at least some compilers do implement asynchronous.
but I can assure you, the list is much smaller than for volatile, which, disables even the most basic optimization, such as using registers during a calculation loop.
Again, I think Nick's examples suggest that the compiler needs to be more careful with asynchronous than you might think. Cheers, Bill -- Bill Long [email protected] Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120