Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!deimos!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!hirchert
From: hirchert@ux1.cso.uiuc.edu
Newsgroups: comp.lang.misc
Subject: Re: NOT Educating FORTRAN programme
Message-ID: <7300001@ux1.cso.uiuc.edu>
Date: 23 Jan 90 21:21:00 GMT
References: <4540@scolex.sco.COM>
Lines: 29
Nf-ID: #R:scolex.sco.COM:4540:ux1.cso.uiuc.edu:7300001:000:1194
Nf-From: ux1.cso.uiuc.edu!hirchert    Jan 23 15:21:00 1990


Sean Eric Fagan (seanf@sco.COM) writes:
>In article <14199@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>>This is a particularly bad example for you to use.  The optimization
>>that you want the compiler to do without is called "common subexpression
>>elimination".  It is important that your compiler know how to do this
>>optimization even if you do have a '+=' operator.  I wouldn't ever buy
>>a compiler which didn't have this capability.  A compiler without this
>>capability is somewhat behind the state-of-the-art anyway (by about 30
>>years).
>
>	x[i] = x[i] + foo();
>
>vs.
>
>	x[i] += foo();
>
>where one or more of x and i are global.  Oops.  If your FORTRAN copmiler
>optimizes that away, you quite probably, have some problems.

Not in FORTRAN; the function reference foo() is prohibited from altering
anything referenced in the same statement, so it doesn't matter whether x and
i are global or not -- a FORTRAN compiler can do the optimization.

FORTRAN has been described as "the only language in which all the classic
optimization techniques work".  This is just another example.

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications