Subject: hpff-interpret: CCI request concerning HPF_LOCAL inquiry intrinsics

From: [email-masked] (Carl Offner)
Date: Fri, 8 Mar 1996 08:24:08 -0500

---------------------------------------------------------------------------
[email-masked] is a mailing list for corrections,
clarifications, and interpretations related to High Performance Fortran.
Instructions for adding or deleting yourself from this list appear at the
bottom of this message.
---------------------------------------------------------------------------

I am submitting this as a CCI request.

We have run into some problems with the hpf local inquiry intrinsics
(e.g., GLOBAL_TO_LOCAL, GLOBAL_UBOUND, etc.).  These intrinsics are
described as returning information about the

	"actual HPF global array argument associated with an
	HPF_LOCAL dummy array argument".

The problems we see are these:

1.  The actual argument might be an array expression.  This wouldn't
be a problem for things like array bounds information -- I think
Fortran already has a consistent way of defining such things in such
cases (e.g. for assumed-shape arrays).  But what about the MAPPING of
the actual?  Expressions have no mappings, but these intrinsics can be
used to extract global mapping information.

2.  The actual argument might be remapped by the compiler in the
course of processing the subroutine call.  (This would commonly happen
if the dummy argument had a different mapping.)  The user really is
then interested in the "remapped actual".

3.  This could also happen if the compiler (for whatever reasons of its
own) decides to use a different mapping than that specified by the
programmer.  Compilers today are not going to do that, but in the
future one could imagine an optimizing compiler with that kind of
capability.  The user certainly wants information about the real
object, not about whatever appears syntactically specified.

4.  Finally, there is an additional problem:  There are mappings that
can be specified in more than one way.  A compiler will typically not
store the source of the mapping directives -- it will pick some
internal representation for the mapping.  When it reports information
from this internal representation, it may look superficially different
to the programmer, even though it amounts to the same thing.

Furthermore, the representation may depend on things like the number
of processors being compiled for.  To take an extreme case (one could
make up a more realistic case; but this exhibits the problem well
enough), suppose the compiler is told to compile an HPF program for
execution on 1 processor.  It is reasonable for the compiler to decide
internally that all mappings are serial, even if they were specified
as BLOCK in the source program.  Certainly there would be nothing
wrong with reporting a serial mapping, since it would describe
precisely the data layout; but it's not what either the actual or
dummy arguments were described as in the program source.

The point is that there is really no need for the results of these
inquiry intrinsics to be tied syntactically to the actual argument.
All the user needs is the information necessary to write explicit
message-passing code.  The compiler should be able to use whatever
internal representation is consistent with what the user has written,
and to report information based on this internal representation.
I think that's what the user really wants, in any case.

-------

Here is the idea of what we would like to say:  Since the ONLY reason
that a user would ever want to call such a routine is to extract
information in order to perform explicit message-passing, we think
that the routines ought to be defined to return information about

	"the global object of which the dummy argument is a
	local section"

with the understanding that this "global object" is
implementation-defined.

The problem, of course, is that I don't know a standard
computer-language formal way to state this.

			--Carl Offner
			[email-masked]
---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to
[email-masked].
Leave the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------