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.