Subject: 1. CALL FOO(A(i), B(i), C(i), D(i)) is not elemental 2. FORALL/HPF-1 should not admit procedures with side effects

From: "Rex Page" <[email-masked]>
Date: Tue, 28 Jul 92 15:51:30 -0500

Min-You says (<[email-masked] Sat Jul 25 17:17:44 1992>):
> 
>  ... calling functions or subroutines from FORALL itself is not well
> justified yet.  As an example, there is a problem with subroutine 
> (function) calls.  It can be illustrated by the following example:
> 
>       SUBROUTINE FOO (a, b, c, d)
>         REAL a, b, c, d
>         a = ...
>         b = c + d    ! assuming that the original d=c+d was a typo
>       END
> 
> This is a perfect elemental subroutine, and if it is called by
> 
>       CALL FOO (A(I),B(I),C(I),D(I))
> 
> there is with no problem.  However, if it is called by
> 
>       CALL FOO (A(I),A(I-1),A(I+1),D(I))
> 
> the result becomes nondeterminate.

FOO could be invoked elementally, but
neither of the above invocations of FOO is an elemental invocation.
An elemental invocation is one with arrays as actual arguments in
places where the function definition has scalar dummy arguments.

Here is an elemental invocation of FOO:
    CALL FOO (A(1:N), A(0:N-1), A(2:N+1), D(1:N))  ! (Merlin)
However, this invocation is illegal (if N>1) because Fortran
prohibits defining a dummy argument whose associated actual
argument overlaps that of a different dummy argument
(as John Merlin has pointed out).

Consider the following non-elemental invocation in a FORALL:
   FORALL (I=1:N)  CALL FOO (A(I), A(I-1), A(I+1), D(I)) ! (Merlin)
What might this mean?

From the fragments of the discussion that I've seen, it appears
that some people want to base an interpretation on the intent
attribute of the arguments, in effect using IN, OUT, and INOUT to
decide whether to pass copies of the actual arguments or to pass
the actual arguments themselves.  Presumably, one would pass a
copy of an argument whose corresponding dummy had intent IN
(by analogy with the treatment of rhs values in FORALL), and
one would pass the actual argument itself if the dummy had
intent OUT (by analogy with the treatment of lhs variables).

Who knows what should be done with dummies of intent INOUT?
Which read-access occurances use the value on entry to the
FORALL, and which use the "current" value?  And what about
a dummy argument of intent OUT for which the procedure contains
rhs-access?
     SUBROUTINE GOO(x,y)
     INTENT(IN) :: x
     INTENT(OUT):: y
     y = x
     y = y+1
     END
What values for y should be retrieved to compute y+1 to carry
out the invocations in the following FORALL?
     FORALL (i=1:n) CALL GOO(A(i), A(i-1))

It is interesting that when statements like those in FOO and GOO
occur in block FORALLs (with dummies replaced by actuals), the
constructs make sense in the "SIMD semantics" (synchronization
after each statement in the block) that have been discussed for
FORALL:

      expanding FORALL (i=1:n) CALL FOO(A(i), A(i-1), A(i+1), D(i))
   FORALL (i=1:n)            ! means   
     A(i) = ...              !   FORALL(i=1:n) A(i) = ...
     A(i-1) = A(i+1) + D(i)  !   FORALL(i=1:n) A(i-1) = A(i+1) + D(i)
   END FORALL                ! using "SIMD semantics" for block FORALL

      expanding FORALL (i=1:n) CALL GOO(A(i), A(i-1))
   FORALL (i=1:n)            ! means   
     A(i-1) = A(i)           !   FORALL(i=1:n) A(i-1)=A(i)     ! shift
     A(i-1) = A(i-1) + 1     !   FORALL(i=1:n) A(i-1)=A(i-1)+1 ! incr
   END FORALL                ! using "SIMD semantics" for block FORALL

I conclude that making sense of procedures with side effects
that are invoked in FORALL constructs is unlikely to be a
productive way for HPFF to invest its time in 1992.
The July 24 strawvote to preclude side-effects in procedures invoked
in FORALL constructs seems the prudent path to follow.  HPF-2
could extend the interpretation to procedures with side effects
if appropriate semantics were discovered.

Rex Page