optimization (was Re: volatile)

[Barry Margolin]

In article <174 at obie.UUCP> wes at obie.UUCP (Barnacle Wes) writes:
>In article <20065 at think.UUCP>, barmar at think.COM (Barry Margolin) writes:
>> 	a = b;
>> 	a = b;
>> It doesn't take much of a flow analysis to determine that the second
>> statement is redundant.  Most peephole optimizers will hack this.
>Aha!  But this code is not always redundant!

I know, but it usually is.  And that's the whole point of "volatile":
it tells the compiler not to assume that such code is redundant, among
other things.  You certainly wouldn't want a compiler to generate
double accesses for all such cases, just the ones where a or b is
volatile.

Proponents of restricting the compiler might claim that programmers
rarely write such things unless they actually mean it.  However,
programmers often write macros, and it's quite possible that such a
redundancy would result from macros that happen to be adjacent.


Barry Margolin
Thinking Machines Corp.

barmar at think.com
uunet!think!barmar