Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: induction variable optimization
Message-ID: <5603@brl-smoke.ARPA>
Date: Sun, 8-Feb-87 00:15:15 EST
Article-I.D.: brl-smok.5603
Posted: Sun Feb  8 00:15:15 1987
Date-Received: Sun, 8-Feb-87 08:34:25 EST
References: <182@ndmath.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <182@ndmath.UUCP> dean@ndmath.UUCP (Dean Alvis) writes:
>     for(i=0;i<10;++i)   j += i*7;
>  evaluates to:
>     for(i=0;i<70;i += 7)  j += i;
>... following code which depends on the value of i may not work correctly.

I suspect the article in question was merely using C to illustrate
the concept, not claiming formal equivalence under all circumstances.
Such optimization is usually done at a point inside the compiler where
the original C code no longer exists but has been turned into parse
trees.  Certainly, correct optimization would require fixing up the
final value of variable `i', if it were used after the loop.

Note that experienced C programmers often have already performed such
program transformations in their heads and written the "optimized"
code sequence; this is partly due to the fact that the original C
compilers didn't do much optimization.  So long as an optimization is
guaranteed never to alter program semantics, it really should be done
by the compiler rather than by the programmer, who generally has more
important things to worry about.