[MPI3 Fortran] MPI buffer arguments - void and call-by-reference

[Bill Long]

N.M. Maclaren wrote:
> On Feb 16 2009, Bill Long wrote:
>>
>>> Ugh.  I have thought of a case where even VOLATILE doesn't block
>>> copy-in/copy-out, but it's irrelevant to this debate.
>>
>> That it is irrelevant is reassuring, although it would be interesting 
>> to see the case. If it were relevant, then ASYNCHRONOUS would be 
>> ineffective as well.  Copy-in/copy-out is blocked by two constraints 
>> in the standard (C1232 and C1233) in which VOLATILE and ASYNCHRONOUS 
>> are interchangeable.  In regards to how they affect copy-in/copy-out, 
>> these two attributes are identical. 
>
> That's almost true, though I can produce cases where ASYNCHRONOUS allows
> copy-in/copy-out and VOLATILE doesn't; again, I am 99% sure all of them
> are irrelevant.
>
> The example I originally referred to is the following:
>
> SUBROUTINE Fred
>    REAL, VOLATILE :: array(10,10)
>    INTEGER :: n
>    DO n = 1,10
>        CALL Joe(array(n,:))
>    END DO
> CONTAINS
>    SUBROUTINE Joe (arg)
>    REAL, VOLATILE :: arg(10)
>    ...
>    END SUBROUTINE Joe
> END SUBROUTINE Fred

This program directly violates C1232.  The same program with VOLATILE 
replaced buy ASYNCHRONOUS violates the same constraint. Neither is a 
valid Fortran subprogram and the compiler is free to not produce any 
object code.


>
>
>> In the cases relevant to the MPI discussion, there is essentially no 
>> difference between VOLATILE and ASYNCHRONOUS is regards to code 
>> motion across a call site.  The caller cannot tell if the callee 
>> contains a WAIT statement, and even if it could, would be hard 
>> pressed to determine if that particular WAIT statement had anything 
>> to do with a particular asynchronous variable. Effectively, all 
>> motion of code involving a variable with either the volatile or 
>> asynchronous attributes across a call site is suppressed by the 
>> optimizer.   The difference is that a variable can get the 
>> ASYNCHRONOUS attribute implicitly, whereas VOLATILE must be 
>> explicitly specified.
>
> That's not true.  It is true only for external calls (i.e. to procedures
> of properties unknown to the compiler).  

Which is exactly why I started the paragraph with "In the cases relevant 
to the MPI discussion...".  All of the calls to MPI routines are 
external calls.  Before laying our flame bait like "That's not true", it 
would really help if you actually read the paragraph to which you are 
replying.



>
>> The definitions and references of volatile variables that the are 
>> exceptional (compared to nonvolatile variables) are, by their nature, 
>> asynchronous.  The core difference between VOLATILE and ASYNCHRONOUS 
>> is that the compiler knows exactly where the asynchronous activity is 
>> coming from - the Fortran I/O system.  Since the I/O system is part 
>> of the processor, it might be able to narrow the scope of 
>> optimization suppression compared to the volatile case.  But, as 
>> noted above, for a standard-conforming program, the cases where this 
>> makes an actual difference are slim.
>
> Really?  Consider a program that transfers into a buffer, does a
> decomposition/FFT/whatever on it, and transfers it out again.  A very
> common paradigm.  If the compiler can 'see' the source of the code that
> does the decomposition/FFT/whatever, and can tell that there is nothing
> in it that could change the pending status, it can optimise ASYNCHRONOUS
> just like ordinary data.  But it can't do that for VOLATILE.

That analysis is valid as long as ASYNCHRONOUS is limited to Fortran I/O 
as is the case currently.  Then the compiler "can tell", as you note 
(assuming it can 'see' the source).  Remove the restriction that 
ASYNCHRONOUS is tied to Fortran I/O and the analysis falls apart.  A 
good argument for not using ASYNCHRONOUS for MPI routines.


-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120