Subject: [[email-masked]: Your example]

From: Alan Karp <[email-masked]>
Date: Tue, 21 Jul 92 14:18:29 -0700

...

	   1) Any rewrite can't introduce a temporary larger than a scalar.

   ----> I disagree. The compiler will generate large temporaries so I
   ----> can, too.

Not necessarily true. The compiler can stripmine out some temporaries I can't.

----> Probably, but it can optimize away some of them and stripmine
----> some others. It has been my experience that the programmer knows
----> how to stripmine and will when memory or performance becomes an
----> issue. Of course, it is always better to do it automatically.

   This is a clarity/optimization issue. If I have to create a temporary or
   two for each FORALL construct, I might wind up with 30 or 40 temporaries
   cluttering up a FORALL-laden subroutine.

   ----> I agree, but it is a matter of balance. Introducing one or two
   ----> temporaries per loop isn't a problem; introducing 100 is. We
   ----> need to see what real code looks like and if it can be rewritten
   ----> conveniently. 

I showed you an example from real code. I'm an applications developer; not
a compiler writer, and I know what I'd have to do if I didn't have FORALL.

----> I, too, am an applications guy. However, in my previous life in
----> IBM, I did a lot of code porting and benchmarking of other
----> peoples' codes. Perhaps this experience has made me more
----> sensitive to issues of semantic clarity.

                     ...

	   3) I'm not willing to generate more than one DO loop nest.

   If I'm going to generate a bunch of DO loops, then I might as well stick
   with F77.  

   ----> Why not, unless you need to generate dozens? My point is that it
   ----> is better to stick to F77 then add something dangerous like
   ----> FORALL.

Here is a major point  of disagreement: I don't accept that single stament
FORALL is dangerous. I can see your point about block FORALL, that unless I
see the FORALL part, the statement A(I) = A(I+1) has a different meaning.
However, I don't believe this argument applies to single statement FORALL,
since the FORALL is part of the same statement.

----> Single statement FORALL is not as bad. Agreed. However, it is
----> still a little dangerous and, I believe, quite unnecessary
----> except for notational convenience. Whether or not its dangers
----> and its deviation from the F90 standard warrant its inclusion
----> will depend on how convenient. Certainly, the case you sent me
----> does not warrant it. Others, such as the one I gave in my first
----> note might.
---->
----> I still think that the one liner is dangerous. A programmer
----> might be surpised at the answers when changing
---->
----> FORALL(I=2:N)A(I)=A(I)+1.0 to FORALL(I=2:N)A(I)=A(I-1)+1.0
---->
----> Using conventional DO loops might not perform well, but it will
----> give the expected result. There might be no excuse for not
----> noticing that the statement is under a FORALL, but I guarantee
----> that I will do it more than once.

   That said, here is an example:

                       ...

   ----> This code does manually what the compiler would do with FORALL.

Not true. You have only given one possible implementation of this. This
particular exmaple is a scatter-add, and it can be done without creating
any temporaries if one has the appropriate hardware.

----> If one has the proper hardware, I would expect the compiler
----> optimization to eliminate the temp array. I could put in a
----> directive to tell the compiler that the array is a temp, but I
----> would hope the compiler could detect this use. (What about it,
----> compiler people?)

   ----> The difference is that I can see that I want the old values of
   ----> A. With FORALL I can interpret your statement as meaning "Use the
   ----> current values of the elements of A, not the value on loop entry".
   ----> 
   ----> What do you say? Should we forward this correspondence to the
   ----> Forum?

Yes, let's forward this conversation to the forum (which I have done).

----> I would like to get these issues in front of a wider audience.
----> What do you think? Someone on this forum will almost certainly
----> end up as referee, so let's hear it. Any objections?  I would
----> prefer to have a point/counterpoint. We could do it as two
----> separate papers or as one paper. Interested, Rich? The paper
----> could be expanded into one for a general audience by including
----> David Loveman's overview as an introduction. How about it,
----> David? Where to you think it should go - CACM, Fortran Journal,
----> or ???

	   Rich Shapiro

----> Alan Karp