From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23693 invoked by alias); 13 Oct 2004 15:22:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 23653 invoked from network); 13 Oct 2004 15:22:36 -0000 Received: from unknown (HELO nondot.org) (128.174.245.159) by sourceware.org with SMTP; 13 Oct 2004 15:22:36 -0000 Received: by nondot.org (Postfix, from userid 501) id B79E417C2B2; Wed, 13 Oct 2004 11:39:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by nondot.org (Postfix) with ESMTP id B3E6224C3BB; Wed, 13 Oct 2004 10:39:41 -0500 (CDT) Date: Wed, 13 Oct 2004 16:06:00 -0000 From: Chris Lattner To: Daniel Berlin Cc: Geoffrey Keating , Mark Mitchell , Subject: Re: Optimizing of explicit temporary storage In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-10/txt/msg00517.txt.bz2 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/