H. Data Mapping and Layout in Subprogram Interfaces

H..1 Introduction

The data mapping directives (see Section 5) and the layout directives (see Section 6) can also be used to describe the mapping and layout of dummy arguments.

The mapping of each such dummy argument may be related to the mapping of its associated actual argument in the calling main program or procedure (the ``caller'') in several different ways.

full specified mapping

The directive describes the mapping of the dummy argument. However, the actual argument need not have this mapping. If it does not, it is the responsibility of the compiler to generate code to remap the argument as specified, and to restore the original mapping on exit. This code may be generated in either the caller or in the called subprogram.

underspecified mapping

The mapping is underspecified. The called subprogram must accept the mapping of the actual argument if it is a specialization of the mapping of the dummy argument (see section 7.4). Otherwise, remapping takes place in the same way as for full specified mappings.

inherited mapping

The dummy argument has the INHERIT attribute. The called subprogram must accept every mapping of the actual argument, a redistribution takes never place.

With the RANGE directive the user can be more specific about the possible mappings.

H..2 What Remapping is Required, and Who Does It

The ADAPTOR compiler will generate the code for the remapping in the called subprogram. So it is usually not necessary to provide an explicit interface for the called subprogram in the caller. This approach has been chosen for the following reasons:

• If the subprogram needs shadow edges, an additional local copy of data can be avoided.
• If the subprogram cannot deal with every actual mapping that is a specialization of the dummy argument, it might chose a more specific distribution. As the routine itself is responsible for the remapping, double remappings can be avoided.

Therefore it is not absolutely necessary to provide an explicit interface. Nevertheless, it is recommended for the following reasons:

• HPF 2.0 requires explicit interfaces if arguments are remapped. Therefore explicit interfaces increase the portability.
• An explicit interface will allow that the caller can also do the remapping. For optimizations, this might sometimes be more useful.

Attention: Within local and serial routines (EXTRINSIC("LOCAL",...), EXTRINSIC("SERIAL",...)), the called routine will not do any remapping. In this case, an explicit interface is mandatory if a redistribution is necessary.

H..3 Inherited Mappings and the Range Directive

If the INHERIT attribute is specified for a dummy argument, the called subprogram must accept any mapping of the actual argument. The actual argument will not be redistributed. There must not be any other mapping directive (DISTRIBUTE or ALIGN).

The RANGE directive is used to restrict the possible mapping formats of the actual argument.

      SUBROUTINE SUB (X)
      REAL X(:,:)
!hpf$ INHERIT X
!HFP$ RANGE X (block(),block()) (*,GEN_block())

The object in the RANGE directive must have the INHERIT attribute. The mapping of the actual argument must be a specialization of at least one of the format-clauses in the RANGE directive.

Attention: There is no runtime check to verify that the actual argument has really a certain mapping

         REAL A(100, 100, 100)
!hpf$    distribute A(block, *, CYCLIC)

         CALL SUB( A(:,,:,1) )          ! Conforming
         CALL SUB( A(:,,1,:) )          ! Nonconforming
         CALL SUB( A(1,,:,:) )          ! Nonconforming
            ....

         SUBROUTINE SUB(X)
         REAL A(:, :)
!hpf$    INHERIT X
!hpf$    RANGE X (block, *)

H..4 Passing Array Sections

In the most situations, ADAPTOR will use copy-in and copy-out for array sections passed to subprograms. The only exception is given for inherited mappings.

      REAL a(n,n)
      ...
      CALL sub (a(2:n:2,:),a(1:n:2,:))
      ...

      SUBROUTINE sub (x, y)
      REAL x(:,:), y(:,:)
!hpf$ distribute x(block(),block()) onto *
!hpf$ INHERIT y
      ...
      END SUBROUTINE sub

H..5 Some Remarks about Efficiency

The more underspecified a distribution is, the more general is the code.

• For full specified mappings the compiler can verify that two objects have the same mapping.

        SUBROUTINE sub (A1, A2, N)
        REAL A1(N), A2(N)
  !hpf$ distribute (block) :: A1, A2
        A1 = A2    ! same distribution, no communication
        END SUBROUTINE sub
  

• For underspecified mappings (here the missing onto-clause) the compiler must assume that A1 and A2 are distributed onto different processor arrangements.

        SUBROUTINE sub (A1, A2, N)
        REAL A1(N), A2(N)
  !hpf$ distribute (block) onto * :: A1, A2
        A1 = A2    ! distribution can be different (communication)
        END SUBROUTINE sub
  

• For underspecified mappings the ALIGN directive should be used to indicate relation between data.

        SUBROUTINE sub (A1, A2, N)
        REAL A1(N), A2(N)
  !hpf$ distribute (block) onto *:: A1
  !hpf$ align (I) with A1(I) :: A2
        A1 = A2    ! aligned, no communication
        END SUBROUTINE sub
  

The following example shows how the mechanism can be used to realize efficient code for different distributions.

      integer, parameter :: N1=10, N2=2*N1, N3=4*N1, N4=8*N1

      real, dimension (0:N1,0:N1) :: A1
      real, dimension (0:N2,0:N3) :: A2
      real, dimension (0:N3,0:N3) :: A3
      real, dimension (0:N4,0:N4) :: A4

!hpf$ align A1(I,J) with A4(8*I,8*J)
!hpf$ align A2(I,J) with A4(4*I,4*J)
!hpf$ align A3(I,J) with A4(2*I,2*J)

      call SUB (A1, A2, N1)
      call SUB (A2, A3, N2)
      call SUB (A3, A4, N3)

      subroutine SUB (X, Y, N)
      real X(0:n,0:n), Y(0:2*n,0:2*n)
!hpf$ distribute Y(block(),block()) onto *
!hpf$ align X(i,j) with Y(2*i,2*j)
      ...
      end subroutine SUB

• The actual mappings are always specializations of the dummy mapping of x, the alignment of the actual argument for y is also true. So there will be never redistributions.
• The code for the subroutine will be still very efficient.
• This example might not be efficient when using inherited distributions with the RANGE directive.

H..6 Differences to HPF

Due to the fact that this kind of directives could be combined and the new standard allows also underspecified mappings, we gave up this terminology and introduced a terminology based on underspecified mappings.

• A full specified mapping for a dummy argument is like the prescriptive directive of HPF.
• A descriptive directive describes the mapping of the dummy. It is the responsibility of the caller to insure that the actual as passed has this mapping. Similarly, remapping to restore the original mapping on exit must also done by the caller. HPF 2.0 does not make any longer a difference between descriptive and prescriptive directives, an explicit interface is always required.
• A transcriptive directive is used to let the mapping unspecified. The called subprogram must accept the mapping of the argument as it is passed. Of course this means that the caller must pass this mapping information at run-time. This corresponds to the underspecified mappings of dummy arguments.