Advice to implementors.RESIDENT without a variable list guarantees that no one-sided communication outside of the ON processor set will be generated by the callee. Such a procedure can be called only on the ``active'' processors, unless the runtime system has additional constraints (for example, if the runtime system requires all processors to participate in collective communications).

The other forms of RESIDENT provide information that could be propagated interprocedurally. For example, if the actual argument to a subprogram is asserted to be RESIDENT and is passed transcriptively, then anything that is aligned to it in the callee will also be RESIDENT. If the information is not propagated, the only result will be less optimization. (End of advice to implementors.)

Advice to users.Although the RESIDENT assertion applies interprocedurally, it is by no means certain that all compilers will make use of this information. In particular, separate compilation limits the propagation that can take place. It is therefore good practice to include a RESIDENT clause both in the caller's ON directive and in the callee. (This assumes that the assertion is true, of course!) This ensures that the compiler has the RESIDENT information available when it is compiling both ends of the procedure call. This is especially useful for RESIDENT clauses without a variable list; knowing that all data accessed is local allows many optimizations that are not otherwise possible. (End of advice to users.)

Locality information is particularly critical interprocedurally. Here, the RESIDENT directive without a res-object-list can be used to good advantage. Consider the following extension of the block-structured example from Section 9.2.4:

!HPF$ PROCESSORS PROCS(NP)
!HPF DISTRIBUTE X(BLOCK) ONTO PROCS

! Compute ILO(IP) = lower bound on PROCS(IP)
! Compute IHI(IP) = upper bound on PROCS(IP)
DONE = .FALSE.
DO WHILE (.NOT. DONE)
  !HPF$ INDEPENDENT
  DO IP = 1, NP
    !HPF$ ON (PROCS(IP)), RESIDENT
    CALL SOLVE_SUBDOMAIN( IP, X(ILO(IP):IHI(IP)) )
  END DO
  !HPF$ ON HOME(X) BEGIN
    CALL SOLVE_BOUNDARIES( X, ILO(1:NP), IHI(1:NP) )
    !HPF$ RESIDENT
    DONE = CONVERGENCE_TEST( X, ILO(1:NP), IHI(1:NP) )
  !HPF$ END ON
END DO

Recall that the INDEPENDENT IP loop performs a computation on each subdomain's interior, where a subdomain is mapped to a particular processor. The first RESIDENT clause additionally informs the compiler that no subdomain uses data from another processor. Without this information, the compiler would have to assume a worst-case scenario in which each subdomain performed its updates based on non-local read-only data. Any nonlocal data could not be written by another processor without violating the tt INDEPENDENT directive; however, if the data were not updated (for example, a large lookup table) it could be stored remotely. Particularly on nonshared-memory machines, access to this remote data would be difficult. The RESIDENT clause ensures that this possibility need not be considered. All data required by SOLVE_SUBDOMAIN is stored locally. The second RESIDENT clause asserts that all data for CONVERGENCE_TEST is stored on the same processors that store X. The same cannot be said for SOLVE_BOUNDARIES, which does not fall in the scope of the RESIDENT directive. For example, there might be a processors arrangement other than PROCS with necessary data. Accessing this data might well cause a bottleneck in the computation as described above.

Again, note the usefulness of RESIDENT clauses in giving the compiler information. Few compilers would be able to unravel nontrivial assignments to ILO and IHI, and no current compiler would even attempt to understand the comments in the above code fragment. End of advice to programmers.