(j3.2006) (SC22WG5.4154) Question about our design for associate names

[Van Snyder]

The relationship between associate names and selectors is very much like
the relationship between dummy arguments and actual arguments, but not
exactly the same.

We didn't apply the restrictions on arguments in 12.4.1.7 in 04-007
(12.5.2.3 in 09-007r3) to associate names and their corresponding
selectors.

In one of my program units, I have a 6-D array assignment

    newField ( :, :, &
      & 1+lowerLon : lowerLon+grid%noLons, &
      & 1+lowerLst : lowerLst+grid%noLsts, &
      & :, : ) = grid%field

in which both newField and grid%field are pointers.

The compiler can't deduce that the targets don't overlap, so it makes a
temp.  I noticed this one because I got "I'm sorry Dave, I can't do
that," an out-of-memory run-time diagnostic.  I'm sure my program is
full of array assignments that don't need temps but for which the
compiler can't deduce they're not needed -- so it makes them, thereby
slowing down execution.

A test like address(a)+size(a) <= address(b) and address(b)+size(b) <=
address(a) can deduce there's no overlap in a=b, but it's probably
hopeless to test at runtime for things like x(i:j:k)=x(l:m:n),
especially with more than one dimension, because the cost of the test
could be more than the cost of using a temp.  A programmer could know,
for example, that k==n and mod(l-i,k)/=0.  I don't know what to write in
the multidimensional case, but I bet it's a mess.

Malcolm suggested hiding the assignment in a procedure.  By applying the
rules in the above cited subclauses, the compiler can deduce it doesn't
need a temp.  For big enough assignments, the benefit of not using a
temp overcomes the overhead of a procedure invocation.  But it adds
maintenance cost to the code, and for smaller assignments the program
still has the cost of a trip to the allocator, which I suspect is nearly
independent of the size of the temp.  I can cross my fingers and hope
for inlining, but many processors can't inline at all, and most that do
can only do so if I mention all of my program unit files on the command
line, which is incompatible with make.

It would be useful if I could get the "no overlap" semantics with an
associate construct, something like

  associate ( a => newField ( :, :, &
            &                 1+lowerLon : lowerLon+grid%noLons, &
            &                 1+lowerLst : lowerLst+grid%noLsts, &
            &                 :, : ), &
            & b => grid%field )
    a = b
  end associate

which of course I can write but it doesn't help anything because we
didn't apply the argument restrictions to associate names.

Do we want to

(1) add the restrictions to associate names
    (a) by way of an interp against 2003,
    (b) in 2008 and announce an incompatible change, or
    (c) in 2013 and announce an incompatible change, or
(2) not add the restrictions?

The second choice will result in a feature request for a "these things
don't overlap" declaration that would have effect in the construct or
scope in which it appears.  It therefore couldn't tell the compiler that
you know the values of i..n are such that there's no overlap in
x(i:j:k)=x(l:m:n).

An alternative is an execution construct that only allows assignment
statements in its body and says "there is no overlap in any of the
contained assignments."

I think it would be simpler to add the restrictions than to invent a new
declaration or construct (especially since I've already drafted the
interp paper).

-- 
Van Snyder                    |  What fraction of Americans believe 
Van.Snyder at jpl.nasa.gov       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.