Xref: utzoo comp.lang.c:10609 comp.lang.fortran:716
Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!pacbell!ames!killer!tness7!tness1!nuchat!sugar!ssd
From: ssd@sugar.UUCP (Scott Denham)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Re: no noalias not negligible - a difference between C and Fortran - long
Message-ID: <2081@sugar.UUCP>
Date: 4 Jun 88 06:19:59 GMT
Article-I.D.: sugar.2081
References: <54080@sun.uucp> <7879@alice.UUCP> <21727@amdcad.AMD.COM>
Organization: Sugar Land UNIX - Houston, TX
Lines: 25
Summary: the ability to disclaim recursion is essential

In article <21727@amdcad.AMD.COM>, tim@amdcad.AMD.COM (Tim Olson) writes:
> In article <7879@alice.UUCP> ark@alice.UUCP writes:
> | I don't really think there's much here that noalias would help:
> | the object code has to fetch dy[i], add da, multiply by
> | dx[i], and store it in dy[i] and aliasing is irrelevant to
> | each of these operations.
> 
> But that forces each iteration of the loop to be performed sequentially.
> I believe the original intent was to guarantee non-overlapping arrays to
> allow vector machines to compute the loop iterations in parallel.
> 
> 	-- Tim Olson

 There is a real need to be able to assure the compiler that there is no
 recursion present in an expression in which it is impossible for the
 compiler to decide this for itself from the information available in
 the code. This is particularly true in subroutines - the designer can
 know things about the values of arguments that the compile could never
 guess, and in the case of any doubt, the compiler must play it "safe".
 IBM made a serious misjudgement in their first attempt at a vector 
 Fortran compiler and included no such facility - and it took some very
 nasty coding to "fool" the compiler into vectorizing code that when 
 written in a straightforward way left open the possiblity that the 
 loop would not give consistent results if pipelined or split into 
 parallel tasks.