Re: Optimizing of explicit temporary storage

[Chris Lattner <sabre at nondot dot org>]

On Wed, 13 Oct 2004, Daniel Berlin wrote:

> > 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;
>
> >> Chris, am i on crack?
> >
> > I don't know Dan, it's hard for me to say, are you?  :-)
>
> :)
>
> Also, isn't your thesis on automatic conversion of programs to use pool
> allocation?
>
> Won't that change malloc->pool_alloc?

Yes, that's the first chunk of my thesis work, and falls into the "other
stuff as well" catagory.  :)  Note, however, that the generated code is
substantially different than the libstdc++ style of pools.  From my
understanding, libstdc++'s pool allocator is basically a malloc
replacement by now that allows multiple heaps.  The code generated by my
pool allocation xform ends up using short lived pools as much as possible,
perhaps most similar in spirit to the GCC zone collector.  For example, if
you have two std::sets with elements of the same types, the LLVM pool
allocator would put the nodes into different pools.

> Or is this something you didn't plan on making the default in LLVM?

It's not something that will be default for a long time (perhaps ever?).
First of all it's not robust enough or predictable enough yet.  Second, I
think that automatic pool allocation is an aggressive enough
transformation that it should be enabled explicitly by the user.  OTOH,
the underlying heap analysis may become the default AA in the future,
we'll just have to see.  Currently LLVM uses a pretty trivial alias
analysis by default.

-Chris

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