Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!apple!oliveb!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 8x:  pointers and optimization
Message-ID: <13961@lanl.gov>
Date: 27 Jun 89 23:19:55 GMT
References: <2773@elxsi.UUCP>
Distribution: usa
Organization: Los Alamos National Laboratory
Lines: 71

From article <2773@elxsi.UUCP>, by corbett@beatnix.UUCP (Bob Corbett):
>      There have been articles posted to this group claiming that pointers
> make optimization impossible and that the SET RANGE and IDENTIFY statements
> would not affect optimization.  Those claims are simply wrong.

I haven't seen any such articles.  Could you forward them to me?
I have made a comment that is roughly similar to the above claim:
SET RANGE and IDENTIFY are _easier_ to optimize than the corresponding
pointer usage.  I have given demonstrations in _both_ these cases.
My claim is that if what I want to do set a range limit, then I don't
_need_ pointers, I would rather have _just_ SET RANGE.  The same goes
for identify: it what I want to do is identify, I don't _need_ the full
power (and complexity to optimize) as pointers give,  I would rather
have _just_ IDENTIFY.

> [...]                                                   The SET RANGE
> statement makes it more difficult to tell when references to array elements
> overlap.

Read the old proposal again.  The SET RANGE statement _CAN'T_ cause
array elements to overlap!  The SET RANGE statement causes _no_ form
of aliasing _AT_ALL_!  All it does is limit the visible elements
of a single array:

      REAL, RANGE :: A(100,100)
      ...
      SET RANGE (2:99,2:99) A
      ...
The reference A(3,60) still refers to the _same_ element after the
SET RANGE statement as it did before.  The only differrence is that
A(1,1), for example, is out of bounds; and A as a whole array is now
conformable to a 98 by 98 array.  The SET RANGE statement did _not_
rename, remap, overlay, or alias _any_ part of A with any other part
of A or with any othe data object.

> [...] 
>        IF (P) THEN
> 	   IDENTIFY (X = A)
>        ELSE
> 	   IDENTIFY (X = B)
>        END IF
> 
>        X = Z
> 
> was allowed.  Thus, adding pointers does not make optimization harder than
> the IDENTIFY statement would.  However, pointers offer more functionality
> than the IDENTITY statement.

Nothing comes for free.  The additional functionality of pointers _does_
make optimization harder (or impossible) in contexts where IDENTIFY would
not.  Consider an example similar to yours:

       IF (P) THEN
         IDENTIFY (X = A)
       ELSE
         IDENTIFY (X = B)
       END IF

       CALL SUB(X,Z)

       X=Z

Is X aliased to Z in any way?  With IDENTIFY the answer can be determined
_locally_.  In the above, the answer is NO.  The subroutine call CAN'T
alter the definition of X (it can alter the value _only_).  If the alias
were accomplished with pointers, however, the answer could _NOT_ have
been locally determined.  This is because pointer assignment CAN be
done within the subroutine.  Only interprocedural analysis can determine
the possibility of aliasing if pointers are involved.  As a result (since
Fortran is separately compiled), the version with pointers would _always_
have to assume that aliasing _had_ occured.