Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!levels!ccml From: ccml@levels.sait.edu.au Newsgroups: comp.lang.misc Subject: Re: C vs. FORTRAN aliasing Message-ID: <15704.274a7509@levels.sait.edu.au> Date: 21 Nov 90 12:37:29 GMT References: Organization: Sth Australian Inst of Technology Lines: 45 In article , 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 | > +---------------------------+------------------+-------------+