Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!necntc!ima!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: optimization (was Re: volatile)
Message-ID: <20224@think.UUCP>
Date: 26 Apr 88 17:44:34 GMT
References: <12578@brl-adm.ARPA> <1988Mar25.172355.348@utzoo.uucp> <20065@think.UUCP> <174@obie.UUCP>
Sender: usenet@think.UUCP
Reply-To: barmar@fafnir.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 24

In article <174@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes:
>In article <20065@think.UUCP>, barmar@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@think.com
uunet!think!barmar