🚀 go-pugleaf

In article <RANG.90Nov18160113@nexus.cs.wisc.edu>, rang@cs.wisc.edu (Anton Rang) writes:
> Another thread I probably should avoid....
ditto :-)
> 
>   Suppose that I have a FORTRAN subroutine which takes two parameters
> which it may modify, X and Y.  Assume that the array A is declared
> somehow; exactly how isn't important.  Suppose you have the code:
> 
> 	SUBROUTINE BLAH(X,Y)
> 	INTEGER X,Y
> 	X = 3
> 	Y = 2
> 	IF (A(X) .EQ. 0) ...
> 
>   Translating this to C, you get: 
  [c example deleted]
> 
>   A compiler for FORTRAN can optimize the test to be A(3) since it
> knows that the assignment to Y can never change X.  A compiler for C,
> in the absence of interprocedural aliasing information, cannot do the
> same.
Assuming that there was no 'EQUIVALENCE (a,b)'  in the routine
which does the 'CALL BLAH(a,b)'!

I would argue that a compiler can easily optimize that test to A(3) if
the subroutine contained 'PARAMETER X=3' but other circumstances need
care.  That would of course be pretty close to C's '#define'.

Martin Leadbeater
Acad. Computing Service
S.A. Institute of Tehcnology 

> 
>   The interprocedural aliasing problem is NP-hard in the presence of
> multi-level pointers or reference parameters (sorry, my refs are at
> home right now, but if any cares e-mail me), and so various
> approximation algorithms are used.  For any approximation algorithm, I
> can write (pathological) FORTRAN code which will result in worse code
> being generated by the C compiler.
> 
> 	Anton
>    
> +---------------------------+------------------+-------------+
> | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison |
> +---------------------------+------------------+-------------+