|INTERMEDIATE CODE DESIGN firstname.lastname@example.org (1995-06-24)|
|Intermediate code design email@example.com (David Stone 5887) (1998-01-05)|
|Re: Intermediate code design firstname.lastname@example.org (1998-01-06)|
|Re: Intermediate code design email@example.com (David Chase) (1998-01-06)|
|Re: Intermediate code design firstname.lastname@example.org (Charles Fiterman) (1998-01-08)|
|Re: Intermediate code design email@example.com (Christian von Roques) (1998-01-08)|
|From:||Charles Fiterman <firstname.lastname@example.org>|
|Date:||8 Jan 1998 00:31:57 -0500|
George C. Lindauer wrote:
> David Stone (email@example.com) wrote:
> > (1) Updating operations.
> > Suppose the source language supports updating operations, for example
> > x += y in C.
> > Should this become
> > x = x + y
No. There is one absolute difference between x += y; and x = x + y;
In the former x is only evaluated once. Consider
x[functionWithSideEffects()] += y;
Stepping outside C to the world of partial evaluation the big
optimizations are on the large scale not the small one. Suppose
x and y are objects and + is a method.
x + y is really clone(x) += y
x = x + y; is really
tmp is clone(x)
tmp += y
x = tmp
If there is notation for saying the code improvment
x += y
is legal that's a major win.
[Hey, in Fortran it is, and we all know that's the only language worth
optimizing. I felt way cool when I got i=i+1 down to one instruction on
my PDP-11 Fortran 77 compiler 20 years ago. -John]
Return to the
Search the comp.compilers archives again.