Subject: hpff-interpret: Proposal to disallow INHERIT + DISTRIBUTE combination

From: Carol Munroe <[email-masked]>
Date: Tue, 2 Jul 96 12:33:51 EDT

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

                *************************************
		Should all INHERITs be transcriptive?
                *************************************
	
	An argument for disallowing the combination
		       INHERIT + DISTRIBUTE

This proposal was inspired by an earlier CCI raised by Carl Offner
concerning the combination of INHERIT and DISTRIBUTE directives for
the same dummy array, and related to his current RANGE rewording 
proposal.

When a dummy argument is used in an INHERIT directive, then, as long
as the actual argument is either a whole array or a regular array
section, the template for the dummy argument is a copy of the template
with which the actual argument or its parent array is ultimately
aligned. (In any other case, nothing can be predicted about the shape
or distribution of the template for the dummy argument, and no
explicit DISTRIBUTE attribute is allowed, and such cases will be
ignored in the following discussion.)

A problem of either interpretation or rank arises when a dummy
argument has both an INHERIT attribute and an explicit DISTRIBUTE
attribute. In this case the dummy argument D must

  a) Have the same alignment as the actual argument, but with a copy of the
template with which the actual argument (or its parent array) is aligned, and

  b) Have a default transcriptive distribution of the form

	!hpf$ distribute D * onto *. 

that may be wholly or partially overridden by the explicit DISTRIBUTE
(descriptive, prescriptive, or transcriptive). 

*****************************
The first question raised is:

	"Does an explicit DISTRIBUTION of an inherited dummy logically apply 
	to the (newly copied) template rather than to the dummy itself?"
*****************************

Suppose the answer is "No, explicit distributions are meant to describe the
mapping of the dummy argument itself." This is presumably the answer if the
DISTRIBUTE axis info must match the rank of the dummy argument given as the
distributee. Then what precisely is the sense of the inherited alignment,
when the dummy argument itself is explicitly distributed?  This would
logically contradict the rule that no variable may have both a DISTRIBUTE
and an INHERIT attribute simultaneously and that only ultimate align
targets can be explicitly distributed.

Since the dummy argument itself is stated to be aligned with its
freshly copied template, consistency with all the mapping principles
for all other variables implies that it is the nameless template which
is actually being mapped, so the answer should be "Yes, it's really
the template that is logically being distributed." 

This creates an awkwardness, since the object actually named in a
DISTRIBUTE directive can only be the dummy argument, not the unnamed
template, while the rank of the mapping must agree with that of the
template, not necessarily with the declared rank of the dummy argument
itself. The rules for DISTRIBUTE require the "rank of the distributee"
to equal the number of axes for which mapping information is given.
When the actual argument is an array section of lower rank than the
whole array, or when the actual argument is a whole array aligned with
an template of a different rank from itself, this would force the
DISTRIBUTE directive to appear to contradict that rule. This conflict
between declared and implied rank is highly non-intuitive for users.
Moreover, the correctness of such a DISTRIBUTE directive cannot be
verified during separate compilation of the subprogram, and the compiler
would be hard-pressed to find any advantage in the information it attempts
to convey.

For example:

*****************************
subroutine sub(x,y,z)
real, dimension(100,200) :: x,y,z
!hpf$ inherit :: x,y,z
!hpf$ distribute$ x(block,block,cyclic)
!hpf$ distribute$ y(cyclic)
!hpf$ distribute$ z(block,cyclic)
*****************************

could perhaps be correctly called by a program like the following,

*****************************
program main
real, dimension(100,200) :: a,b,c
!hpf$ template, dimension(100,200,300) :: t1
!hpf$ distribute t1(block,block,cyclic)
!hpf$ template, dimension(100) :: t2
!hpf$ distribute t2(cyclic)
!hpf$ template, dimension(200,300) :: t3
!hpf$ distribute t3(block,cyclic)
!hpf$ align a(:,:) with t1(:,:,*)
!hpf$ align b(*,:) with t2(:)
!hpf$ align c(*,:) with t3(:,*)
call sub(a,b,c)
end
*****************************

but directives like these are ugly to write and to maintain, as they fly in
the face of the Fortran principle that array rank is always determined at
compile time. Furthermore, the distribution directives contain almost no
information that could be used at compile time. For example, the compiler
could not tell whether x's 1st axis in the above example is to be
distributed BLOCK, CYCLIC, or collapsed, or whether z is itself distributed
(block,cyclic), or, as in this case, has its 1st axis collapsed, its second
axis block-distributed, and is replicated over a cyclic-distributed axis.
Included in an interface block, such information could be compared with the
actual subroutine calls and used to remap arguments, but they seem useless
in the routine itself.

********************************
The question that now arises is:

	"Why allow INHERIT + DISTRIBUTE	in the first place?"
********************************

We should consider whether the advantages of being able to redistribute an
align target of a dummy argument outweigh the disadvantages of of
permitting such unreadable and uncheckable syntax. One might argue that it
would suffice to prohibit INHERIT + DISTRIBUTE in cases where the dummy
argument and its inherited template are of different rank, but the example
of the third argument C to the subroutine above shows that even when the
ranks are the same, the alignment can involve permutation of axes or
collapsing plus replicating, so that mapping information for the axes of
the dummy's template do not predict much about specific axes of the dummy.

One of the most likely reasons appears to have been to support Subset
HPF 1.0, which included the INHERIT directive but not the
transcriptive forms of the DISTRIBUTE directive, so users of INHERIT
were obliged to have prescriptive or descriptive DISTRIBUTE directives
to accompany every INHERIT (presumably to avoid implying a
transcriptive mapping that could not be indicated explicitly).

However, the changes to Subset HPF since version 1.1 invalidate this
argument, since HPF 1.1 removed INHERIT from Subset HPF entirely, while
including the transcriptive forms (and all forms) of DISTRIBUTE.

What else is INHERIT + DISTRIBUTE good for? INHERIT is most valuable for
allowing objects to be passed in place, with no remapping, allowing both
any alignment and any distribution, the so-called "transcriptive INHERIT".
It is essential for implementing library code that must accept arguments
with a wide variety of mappings. The allowed types of the mappings can be
detailed if the RANGE extension is implemented. If either the axis mapping
types or the "ONTO" processor arrangement is indicated explicitly, then it
becomes essentially either a "descriptive" or "prescriptive INHERIT".

The old "descriptive INHERIT" allows one to specify mapping attributes
for a nameless template copied from the calling program. But since
neither the shape of the template nor the pattern of alignment of the
dummy is described, this is fairly useless information as described
above, and cannot reasonably be expected to generate more efficient
code than the "transcriptive" INHERIT with a default * ONTO *
distribution. Either a new ALIGN directive to an explicitly declared
template, itself with an explicit distribution would convey much more
useful information to the system. Similarly, useful information could
also be conveyed to the compiler via the optional RANGE directive,
which (according to Carl Offner's latest proposal) can give
an axis by axis description of the mapping or possible range of
mappings of a dummy argument with the INHERIT attribute.  Such
information is probably more useful to the compiler than a descriptive
distribution of the unnamed, copied template, particularly if it is
required to correspond axis-by-axis with the dummy argument itself,
thus avoiding another mixed rank problem.

The "prescriptive INHERIT", which in HPF 2.0 is equivalent to having
both the INHERIT and DISTRIBUTE attributes for an argument in an
explicit interface, does offer some additional functionality by
allowing an arbitrary pattern of alignment to be inherited from an
actual argument, while also choosing to remap the ultimate align
target. But it is hard to imagine an example that could not be handled
in another more efficient fashion.  Inheriting an alignment while
remapping data might seem to offer some advantage if multiple actual
arguments are to maintain an unknown but preexisting alignment with a
template that gets remapped for the duration of the subprogram.
However, it is difficult to see how a system could take any advantage
of this information, since no relation between the arguments would be
indicated in the code. Each of the arguments would have a separate
copy of the old template, and each could have an INHERIT + DISTRIBUTE
mapping preserving the original type of alignment although to an
individually remapped template, but the compiler would have no hint
of their relationship, and dummy arguments would not share a common
template. Certainly no optimization could be done at compile time.

In particular, if multiple actual arguments had an identical alignment
with the same template, it would be far more useful for one argument
to be chosen for redistribution (or aligned with a dynamically
redistributed template, declared in a module) and for the other
arguments to be aligned explicitly with the designated one. Then the
compiler could benefit from knowledge that the arguments were aligned
with each other.

More generally, an arbitrary pattern of alignment can be described via
a list of scalar arguments, which could be passed to a subprogram
along with the aligned array or array section. Such data would permit
the alignment to be described in an ALIGN directive, with the target
TEMPLATE redeclared locally and given any desired explicit mapping.
Thus a more explicit alignment would achieve the same mapping, and its
presence in the subprogram could provide useful information that the
compiler could use.

**********************
	Conclusion
**********************

I hereby propose that the combination of INHERIT + DISTRIBUTE be
eliminated from HPF completely, letting the other rules for INHERIT
stand. Thus each instance of INHERIT would be both a transcriptive
type of alignment plus a transcriptive distribution, with no remapping
desired, and would take the place of the nonexistent syntax ALIGN X *
WITH * (by rough analogy with DISTRIBUTE), plus an implied DISTRIBUTE
* ONTO * for its template. Just as ALIGN and DISTRIBUTE attributes
cannot be combined for the same object, INHERIT and DISTRIBUTE
attributes could not be combined explicitly for the same object.  The
result will be a simplification of the language that preserves its
useful functionality as well as the principle of constancy of rank for
data objects in HPF directives as in Fortran expressions. 

Implementation note: In the interest of supporting any existing codes
that might now use INHERIT + DISTRIBUTE in combination, I would
suggest that HPF 2.0 implementations simply provide warnings that
DISTRIBUTE attributes of INHERITed dummy arguments are replaced by a
default DISTRIBUTE * ONTO * in effect, but not making such a
combination an error that prevents compilation.
---------------------------------------------------------------------------
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] (Chuck Koelbel)
Date: Mon, 8 Jul 1996 17:23:32 -0600

I agree both with Carol's goal (simplifying HPF's arcane subroutine
interfaces) and tactics (making INHERIT mean what programmers think it
means).  There are, of course, details that may get in the way.  For
example, can RANGE tell us everything about INHERITed dummies?  (I suspect
pathological cases of permuting axes in ALIGNs can reduce the effectiveness
of RANGE - after all, the reason for INHERIT in the first place was that we
found incoming distributions that we couldn't describe using just
DISTRIBUTE...)  But these can be debated in subcommittee...

I suggest that discussions continue on the hpff-distribute list, rather
than hpff-interpret (which is supposed to be there for answering questions
about the existing language).

                                                Chuck