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

From: [email-masked] (Chuck Koelbel)
Date: Fri, 8 Mar 1996 12:34:32 -0600

---------------------------------------------------------------------------
[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'll try to get straight to the punch line.  Let me admit up front,
however, that I'm a little hazy on some aspects of EXTRINSIC.

>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.

I thought this is what the original language meant.  (Or was intended to
mean...)

I think of it this way:

The EXTRINSIC callee gets  an area of memory (the dummy argument) and a
data descriptor (not directly visible) from the caller.

GLOBAL_FOO and FOO_GLOBAL routines extract information otherwise
inaccessible from the descriptor.  [Suddenly I'm suspicious that these
routines should be intrinsics - else it's hard to explain where they get
their arguments...]

The "actual HPF global array argument" is an array with (a copy of) that
descriptor and area of memory.  This may not correspond to any particular
syntactic element of the program.

I would agree that the current wording isn't crystal clear (despite being
written by Guy Steele, if I remember right).  But then the whole idea of
EXTRINSIC procedures has always been kind of hard for me to grasp...

Starting from that premise, let's see if any of these problems get clearer.

At 08:24 03/08/96, Carl Offner wrote:
>
>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.

The mental model seems to handle this OK in common cases- the caller has to
build a descriptor, which may not correspond to any array variable or
section thereof.  Indirection arrays break the model by making the
descriptor poorly defined.  But they also break INTENT(OUT) and
assumed-shape dummies.

HPF has rules for when descriptive mappings can be used for dummy arguments
(i.e. when mappings are identical).  Cant we amend the standard so that
GLOBAL_TO_LOCAL & friends are implementation-dependent when a descriptive
mapping cannot be used?  A note to implementors might say "We suggest that
the compiler create the simplest possible descriptor for the other cases -
for example, align the result of an array expression with one of its
inputs."

>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".

This is definitely unclear in the current language.

Using something along the lines of the mental model, we have to say "do the
remapping before constructing the descriptor".

>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.

The same problem (theoretically) occurs in regular HPF code if the compiler
chooses its own distributions.  HPF_DISTRIBUTE may then return misleading
information.

The onus is on the compiler to ensure that if it ignores user advice, then
the results remain consistent.  In particular, GLOBAL_TO_LOCAL should
produce an index that gets you to the expected element.  (In regular HPF,
REDISTRIBUTE must move the right elements to the right places.)  Two
mechanisms have been suggested for doing this:

1. Have the HPF library routines return the truth about what the compiler
is doing.  This basically presumes run-time descriptors are queried (and
updated).

2. Before any HPF library routine is called, remap the data back where the
user said it should go, return the "expected" result, then remap data to
where the compiler thinks it should be.  As an optimization, the compiler
can eliminate the remappings as dead code.

The first option is considered preferable.

You seem to assume that the "actual" is the syntactic element - I think it
is the runtime object.

>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.

You can say the same thing about HPF_DISTRIBUTE in regular HPF.

My interpretation is that the HPF library inquiries can return any valid
representation of the mapping.  Since the representations correspond to
equivalent mappings, this should not matter to the user.  (I suppose some
users will try to reverse-engineer the optimizations on address arithmetic
this way... It will not matter to the *normal* user.)

Is there something in the writeup that says "the mapping specified in the
syntax"?

>The point is that there is really no need for the results of these
>inquiry intrinsics to be tied syntactically to the actual argument.

I agree that there is no need to tie them to the syntax.
Maybe it's just my warped point of view, but I don't think they are...

                                                Chuck

---------------------------------------------------------------------------
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>
---------------------------------------------------------------------------

---

From: <[email-masked]> (Henry Zongaro)
Date: Mon, 11 Mar 1996 12:05:30 -0500 (EST)

Hello,

     I just have a couple of points relating to all of this.

> for example, align the result of an array expression with one of its

I think the HPF document already says enough.  If you check out Section 3.10,
the second paragraph states that, "If there is no explicit interface, then
actual arguments that are whole arrays or array sections not involving vector
subscripts may be remapped at the discretion of the language processor; the
values of other expressions may be remapped in any manner at the discretion of
the language processor."  This implies to me that even though the user cannot
specify a mapping for an expression, the expression will nevertheless have a
mapping.

> remapping before constructing the descriptor".

The second paragraph of 3.10 states that, "If there is an explicit interface
for the called subprogram, . . . the actual argument will be remapped if
necessary to conform to the directives in the explicit interface."  This
describes remapping as affecting the actual argument - it doesn't speak in
terms of an actual that the user specified vs. a remapped actual.  There is
only one actual, it is remapped on the call and becomes associated with a dummy
argument; when the user inquires about the mapping of the associated actual,
the information returned is about the mapping the actual has while it's
associated with the dummy.

> Maybe it's just my warped point of view, but I don't think they are...

Thanks,

Henry