Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: C's sins of commission
Message-ID: <5080@lanl.gov>
Date: 6 Nov 90 20:13:57 GMT
References: <2440:Nov607:32:5890@kramden.acf.nyu.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 23

From article <2440:Nov607:32:5890@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> In article <1990Nov2.052815.22188@murdoch.acc.Virginia.EDU> gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) writes:
>   [ on one type of aliasing problem ]
<>      a[i] = b[i] / c[i];
<>      d[i] = b[i] * c[i];
<   [ Fortran sees separate arrays and loads b[i] and c[i] only once ]
<   [ C sees possible aliasing and loads them twice ]
< Hmmm. I would almost automatically optimize the above into
<   {register double bi = b[i];
<    register double ci = c[i];
<    a[i] = bi / ci;
>    d[i] = bi * ci;}

So would the compiler (a good one anyway).  The problem is that you
are shifting the burden to the programmer (who has enough on his plate
just getting his code to run correctly).  He has no time for these niggly
little optimization issues - especially those that the compiler _should_
solve for him.  To be sure, the programmer may have time to fine-tune
some tune some time-critical fragments of his code: but in that case he
should be able to work on the tough issues that the compiler _can't_
do for him.

J. Giles