Re: Comments on gfortran, coarrays, MPI etc.

[Tobias Burnus <burnus at net-b dot de>]

N.M. Maclaren wrote:
> But this means that gfortran HAS to allow for coarrays being accessed
> by ordinary memory accesses.  No ifs or buts.  In particular, if a
> section of a local coarray is passed as an argument, that can be
> updated as an ordinary array while a NON-overlapping section is being
> updated from another image. [...]
> This is the strongest argument against relying on MPI one-sided
> communication for such things. 

While I do not mind doing communication from both sides, I have no idea
(e.g. for sending data from the local image) where one has to add the
corresponding receive on the other image; thus I do not see how one can
avoid single-sided communication.

> N1814 C526 (page 91, CODIMENSION attribute) makes it clear that coarrays
> must have either the SAVE attribute or allocatable and 8.5.1 (page 188,
> image control statements) states that coarray allocation and
> deallocation is collective.  Unfortunately, there is NO constraint
> requiring all images to call a procedure with a local coarray before
> that coarray is used.  For example: [...]
>
>        IF (THIS_IMAGE() == 1) CALL Fred()
>        SUBROUTINE Fred
>            REAL :: array(10)[*]
>                ! [...]
>                array(:)[n] = 0.0
>
> This means that there will need to be a mechanism to invoke a collective
> for each local coarray as a program starts up - it is NOT feasible to
> wait until it is first called.  Does the gcc system have such a
> mechanism?

(You miss a SAVE.) Regarding a collective initialization: I see the
problem that coarrays can be distributed over a lot of .o files thus I
do not see how one can initialize them, e.g., at start up. I wonder how
other implementations (Cray, g95, Rice) handle this (maybe it is easier
for Cray if the memory address is the same on all nodes and thus images?).

> 5) SYNC_* would be implemented more-or-less as specified -
I see a problem with SYNC MEMORY. It seems to ensure two things:
Preventing a change the ordering and moving variables out of the
register into the memory. That's simple for:

   integer, SAVE :: coarray[*]
   __register_coarray(coarray) ! assume this for the moment*
  coarray = 5
  __sync_memory()
  ... do something ...

due to the "__register_coarray" call the address of "coarray" escapes
and thus the compiler has to assume that __sync_memory has access to
"coarray". However, as soon as one inlines __sync_memory via LTO (link
time optimization), the compiler will realize that it is (typically) a
no-op and thus "coarray" might be optimized away after the
__register_coarray part. (Maybe I missed something; additionally, one
can also modify the middle-end of GCC to make this work, but I thought I
mention this here.)

(* seemingly, __register_coarray cannot be called here for the reasons
Nick mentioned above.)

Tobias