Optimizing of explicit temporary storage

[Mike Stump]

On Oct 12, 2004, at 12:00 AM, Mark Mitchell wrote:
> In C, even given just:
>
>  (void) malloc(16);
>
> it would be surprising to most programmers to optimize away the call 
> because malloc *does* have side-effects on real systems.  For example, 
> on UNIX, it is likely to call sbrk, which result in observable changes 
> in the process state.

There are details (side-effects as you call them) that can be observed 
with gdb, that are not to be interpreted having any relationship with 
the term side-effect or observable behavior in the language standard; 
by this I mean are to be allowed by the optimizer.  In the more general 
standard of a real system, we have to decide which details are 
important (side-effects or observable behaviors) and which aren't, 
that's our job.  As we do higher level optimizations, we have to 
consider exactly which details we want to be side-effects, and which we 
don't want to be, and why.  We can debate just how much information is 
to be required for a particular optimization, that's part of the 
language design.  I'd argue that exactly when sbrk is called under 
malloc isn't an observable side-effect, even on a UNIX system.  I'd 
argue that the value of malloc, likewise, isn't important.

For some languages, this type of optimization is going to be more 
beneficial than for other languages, for C is might not make any 
sense.  For objc or java, I think it might make more sense.  For C, we 
might want to define our language as not permitting it, but for objc, 
to allow it.

Anyway, we can postpone further discussions on this topic until such 
time as someone seriously wants to consider adding it...