[MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846

[Rolf Rabenseifner]

----- Original Message -----
> From: "N.M. Maclaren" <nmm1 at cam.ac.uk>
> >From: "Rolf Rabenseifner"

Nick,

Let's look at
  CALL MPI_Irecv(buf, rq)
  CALL MPI_Wait(rq)
  xnew=buf
and the new value for buf may be received within the MPI_Wait call.

> >To summarize, there are several options:
> > - TARGET buf
> 
> Why should that work? Fortran compilers are required to take
> notice of it only when also operating with POINTER variables. And
> there is nothing stopping them from moving such data dynamically,
> if they update all associated pointers. That's old technology,
> after all.

With
TARGET buf
CALL MPI_Irecv(buf, rq)
CALL MPI_Wait(rq)
xnew=buf

With MPI_Irecv(buf, rq), the implementation of MPI_Irecv can have
made a pointer (stored in or behind rq).
Later on MPI_Wait(rq), the Fortran compiler has to expect
that buf is accessed through this pointer.
Therefore, the compiler must not move "xnew=buf" before the 
MPI_Wait statement.

When I understand correctly, then "TAGET buf" means only
Fortran pointers and the Fortran system has not 
detected such a pointer. Therefore it may be possible that
"xnew=buf" is still moved before the MPI_Wait statement.

Correct?

I see several options to solve the problem:

Option Target-1:

  The TR 29113 enhances the meaning of pointer also to C pointers 
  in the framework of the TARGET attribute.

Option Target-2:

  MPI-3.0 requires that "TARGET buf" works.

  An MPI implementation can implement this by calling
  a Fortran helper within MPI_Irecv that stores such
  a pointer visibly for the Fortran run-time environment
  and that frees this pointer in MPI_Wait.
  An MPI implementation can implement this also
  by requiring the quality of Target-1 from the compiler.

Option Target-3:

  We give up with this solution-path for this code-movement
  optimization problem.

Are there other options?   


> > - Using a call to a dummy routine MPI_F_SYNC_REG(buf)
> >   immediately after MPI_Wait
> 
> That won't work, either, because it doesn't stop copy-in/copy-out
> and other such techniques.

With
CALL MPI_Irecv(buf, rq)
CALL MPI_Wait(rq)
CALL MPI_F_SYNC_REG(buf)
xnew=buf


The content of MPI_F_SYNC_REG is outside the scope of the
Fortran optimization.
I do not see that the compiler is allowed to move 
"xnew=buf" before the MPI_Wait statement because
"MPI_F_SYNC_REG(buf)" may have modified the content of buf.

Therefore the problem is solved.

Correct?
  
If not, please can you show a detailed code, how 
such a compiled code could work and in xnew is at the end
***not*** the value that was stored in buf by MPI_Wait.

> > - Storing buf as a module variable or in a common block
> 
> That won't work, either, for the above reason.

With
COMMON /xxx/ buf
CALL MPI_Irecv(buf, rq)
CALL MPI_Wait(rq)
xnew=buf

The compiler has to expect that MPI_Wait has access to the 
COMMON block /xxx/ and therefore the compiler is allowed to move 
"xnew=buf" before the MPI_Wait statement.

Therefore the problem is solved.

Correct?
  
If not, please can you show a detailed code, how 
such a compiled code could work and in xnew is at the end
***not*** the value that was stored in buf by MPI_Wait.


> >> - (VOALTILE buf, not recommended)
> 
> Why should that work any better than ASYNCHRONOUS? All it says (in
> both
> C and Fortran, incidentally) is "All bets are off - consult your
> vendor
> documentation for what might happen." ASYNCHRONOUS has the right
> semantics.

With
VOLATILE buf
CALL MPI_Irecv(buf, rq)
CALL MPI_Wait(rq)
xnew=buf

By definition of volatile, the compiler has to guarantee
that all accesses to buf are done through the memory
and in the sequence of the application.
It must expect that any library routine call and any 
other thread my write some data into buf; outside the
scope of the Fortran statements.
Therefore the compiler must not move a statement with
buf across any library call.

Therefore, "xnew=buf" cannot be moved before the MPI_Wait statement.

Therefore the problem is solved.

Correct?

Or have I misunderstood the wording of VOLATILE:
Fortran 2008, 5.3.19:
"The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, by means
not specified by the program."
Our MPI_Wait is such a "by means not specified by the program."

Fortran 2008, NOTE 5.25:
"The Fortran processor should use the most recent definition of a volatile object when a value is required.
Likewise, it should make the most recent Fortran definition available. It is the programmer's responsibility
to manage any interaction with non-Fortran processes."

"recent" means, that the sequence must not be modified.
Otherwise "xnew=buf" does not access the recent definition of buf.

Correct?
 
 
> >'ASYNCHRONOUS buf' is explicitly not an option, because
> >a Fortran compiler
> >- that implements Fortran asynchronous input/output
> >  with blocking I/O routines
> >- is allowed to ignore the ASYNCHRONOUS attribute.
> 
> If you are being that legalistic, the problem is insoluble in all of
> C, C++ and Fortran. Sorry, but that IS what the standards say!

Only when I'm wrong with all of my opinions showed above.
 
> >Only compilers with really asynchronous Fortran I/O
> >have to also internally imply the TARGET attribute when
> >the ASYNCHRONOUS attribute is given
> 
> Er, no, they don't. The attributes are different and have subtly
> different properties.
> 
> >> You do not need to be a member of J3. Would you like to join
> >> interop-tr?
> >
> >Most of the internals of the TR, I do not understand.
> >As I see, the list moderator can agree to deliver the few
> >mails from me also to the other members of the interop-tr.
> >It isn't a problem for me to put you, Bill, Nick, Craig,
> >and Reinhold on the CC.
> 
> The problem is when we reply. Unless I leave you in the list
> explicitly,
> you won't see the reply. And duplicating people has other problems.

If I should be on the list, then it is okay for me.

> Regards,
> Nick Maclaren.

Best regards
Rolf

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)