Optimizing of explicit temporary storage

[Kai Henningsen]

sabre@nondot.org (Chris Lattner)  wrote on 12.10.04 in <Pine.LNX.4.44.0410122302530.31127-100000@nondot.org>:

> On Tue, 12 Oct 2004, Daniel Berlin wrote:
>
> > >> Yes, but that's rather a different situation due to the nature of
> > >> Scheme.
> > >>
> > >> 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.
> > >
> > > Well, yes, but
> > >
> > >        int x[65536];
> > >
> > > also results in observable changes in the process state, and we don't
> > > hesitate to optimise it away.
> >
> > I believe LLVM actually does all kinds of promotion that ends up removing
> > malloc calls.   Maybe i'm just misremembering.
>
> Yes, LLVM deletes dead malloc calls and does other things as well.  The C
> spec defines the behavior of malloc/free, and from this description I
> believe that it is safe to do this (e.g. C99 second 7.20.3).  Note,
> however, that Mark's point above about calling sbrk is beyond the
> standard: conformant programs can't know anything about sbrk.

Especially as that is strictly an internal library design decision: there  
are certainly implementations that, say, use mmap() instead, and leave  
sbrk() alone.

MfG Kai