Subject: Proposed HPF feature

From: [email-masked]
Date: Mon, 13 Apr 92 13:00:18 -0500

I should be sending out a discussion of the various flavors of FORALL
loops later today.  In the meantime, here's something forwarded from
Mary Zosel.  I think it bears directly on whether we should think
about user assertions instead of / in addition to parallel loops.

>> Date:    Thu, 02 Apr 92 09:43:03 PST
>> To:      [email-masked], [email-masked]
>> From:    [email-masked] (Mary E Zosel)
>> Subject: hpf wish
>> 
>> 
>> Ken and Chuck
>> The following HPF "wish" was given to me yesterday.  I don't know that
>> it fits cleanly into any of our subgroups.  I'm forwarding it to you -
>> and maybe it is something that I can have 5 minutes at the next HPF
>> meeting to propose.  {It may open up the bucket of worms to ask if
>> we want to standardize directives about vectorization in general.}
>>    -mary-
>> 
>> ----
>> Statements of the following form are very common ...
>> 
>> f(ix) = f(ix) + delta
>> 
>> where ix is a non-unique index vector (actually usually ix(j)).
>>       f and delta are vectors (or arrays) of length less
>>       than ix.
>> 
>> This is used, for example to accumulate information into a node from
>> the surrounding zones.
>> 
>> Currently some compilers incorrectly vectorize this (unsafe without
>> special attentiion).
>> 
>> Other systems provide some ugly subroutine to call which does the
>> correct thing efficiently.
>> 
>> 
>> The spokesman for a primary part of our user community here at LLNL
>> would like to propose that HPF help address this problem.
>> 
>> Specifically, he would like a directive to specify to compilers that
>> ix is non-unique.  Then compilers could recognize this array syntax
>> statement should really be turned into the ugly subroutine call, while
>> leaving the code that the user writes to be clean array statements which
>> are portable between systems.
>> 
>> (If the user has to call the ugly subroutine, it often isn't portable -
>> and it messes up the readability of the code.)
>>

---

From: [email-masked] (Andy Meltzer)
Date: Mon, 13 Apr 92 14:46:32 CDT

> >> and it messes up the readability of the code.)

The current Cray Programming Model has the directive:

	CDIR$ ATOMIC UPDATE
	      f(ix) = f(ix) + delta

The purpose of the directive is to indicate to the compiler that each array
element in the statement which follows must be updated atomically, and may
be updated more than one time.  The compiler is free to do this in any 
way it choses, including calling an ugly subroutine of its own or even
sequentializing.

I'd be in favor of an approach more along this line.

							Andy Meltzer

---

From: Paul St. Pierre <"ptrpan::stpierre"@tle.enet.dec.com>
Date: Tue, 14 Apr 92 09:51:53 EDT

>>       f and delta are vectors (or arrays) of length less

I think this example raises a subtle issue for HPFF.  

Note that the user wants to legalize a particular behavior for a
non-standard-conforming program.  (Many-one array sections must not
appear on the left side, as per 6.2.2.3.2, and the right side is
always evaluated completely before assigning (7.5.1.5).)

The output of a program relying on this behavior will likely be
different for processors that support the HPF directive (however it's
spelled) and processors that don't.  This seems to me contrary to the
spirit of directives, which shouldn't change the semantics of a
program, just its performance.  (I can't recall any other HPFF
proposed directives that have this property, but I could be wrong.)

You may want to discuss whether HPF should be in the business of
legalizing incorrect programs with directives, thereby encouraging
non-portable behavior.

If you decide you do want to do that, I would suggest that the
directive be phrased so that the F90 standard-conforming behavior is
assumed, and the directive provides information overriding that.

--paul