Re: Optimizing of explicit temporary storage

[Chris Lattner <sabre at nondot dot 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.

Assuming standards compliant programs, this can still cause changes in
observable behavior.  In particular, something like this:

malloc(HEAPSIZE-100);   // dead
P = malloc(1000);       // not dead
*P = x;

Would cause *P to trap for a suitable value of HEAPSIZE (the second malloc
would return null) in an unmodified program.  In the optimized program the
second call would not return zero.   However again, portable program's
can't really know the size of the heap (malloc can fail at any time (e.g.
due to fragmentation issues) so the program can't even portably probe) so
this is not an issue.

If we are talking about being a C compiler, I think that's as far as it
goes.  However, almost no programs *only* use features from the standard,
so as a QOI feature, adding an argument to disable this kind of thing
might be useful: -fno-builtins seems reasonable to me.  Note that most
programmers would be very happy to have their memory usage optimized, so
IMHO it should be the default.  Obviously you guys have to choose what you
think is right for GCC.

Also note that the comments above only apply to malloc/free.  We don't do
anything special with operator new/delete, though in the future we might
at link-time (we need to detect that a version with known behavior is
linked to, that a new_handler has not been installed, and potentially
other things).

To me, I consider it a defect in the language that the C++ std (as far as
I can tell) does not explicitly allow optimization of operator new/delete,
just like we can optimize out copy ctors.  In particular, the restrictions
placed on allocation functions (3.7.3.1 in C++2003) specify restrictions
that callers must obey, but does not say anything about side effects or
optimizability or restrictions that implementations and new_handlers must
respect.

> Chris, am i on crack?

I don't know Dan, it's hard for me to say, are you?  :-)

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/