Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?)

pardo@june.cs.washington.edu (David Keppel)
Fri, 15 Jun 90 05:17:53 GMT

          From comp.compilers

Related articles
[7 earlier articles]
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) poser@csli.stanford.edu (1990-06-06)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) larus@primost.cs.wisc.edu (1990-06-07)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) tli@%phakt.usc.edu (1990-06-07)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) moss@cs.umass.edu (1990-06-10)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) cwitty@csli.Stanford.EDU (1990-06-14)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) moss@cs.umass.edu (1990-06-14)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) pardo@june.cs.washington.edu (1990-06-15)
| List of all articles for this month |

Newsgroups: comp.compilers
From: pardo@june.cs.washington.edu (David Keppel)
References: <1990Jun14.032437.5554@esegue.segue.boston.ma.us>
Date: Fri, 15 Jun 90 05:17:53 GMT
Organization: University of Washington, Computer Science, Seattle
Keywords: code, optimize

I (pardo) wrote:
>>[Some languages are standardize to undefined order of evaluation]


John Levine (the moderator) writes:
>>[More the rule than the exception.]


cwitty@csli.Stanford.EDU (Carl Witty) writes:
>[I belive not true for C; only the ``as if'' rule, e.g., where proven
> not to make a difference. (For example, on many machines, integer
> arithmetic really is commutative and associative.)]


John writes:
>[Of course, I don't know what I was thinking.]


I'll stick by my gnus on this one :-) I'll warn you that I'm not the
ultimate expert on this, but I've had several ``ultimate experts''
convince me...


Consider the following:


a[i] = b[i++];


``Yeah, yeah'', I hear you type, ``that's only one example.'' Ok,
then, consider:


struct fs { struct fs next; } foo;
foo->next = foo = (struct fs *)zork;


Well, the address of `foo->next' can be computed before or after `foo'
is assigned. Or how about


foo = (struct fs *)something_legal;
foo = foo->next = (struct fs *)zork;


`foo' can be assigned before `foo->next' is computed or assigned. The
`as if' rule applies to _types_ in this case. For example


int x;
long y;


y = x = (long)value;


The value assigned to `y' must be what would be assigned AS IF the
value was assigned from `x', but there is no insistance that the
assignment actually proceed in that order:


long y = (long)(int)value;
int x = value;


Still not convinced that this is the rule rather than the exception?
Consider bit shifts by more than the word size, order of evaluation of
expressions in a parameter list, the meaning of modulo by a negative
number, and a number of other things that CAN have well-defined
semantics in C but which DON'T have well-defined semantics in C.


Let the goodflame games begin :-)


;-D on ( Careful definition ) Pardo
--
pardo@cs.washington.edu
        {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
[C is very picky in areas like associativity, you have to do a+b+c as
(a+b)+c and not a+(b+c) unless you can prove that the latter two are
entirely equivalent in all ways including possible exceptions. That's
pretty restrictive. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.