From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 665 invoked by alias); 13 Oct 2004 04:06:24 -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 626 invoked from network); 13 Oct 2004 04:06:19 -0000 Received: from unknown (HELO nondot.org) (128.174.245.159) by sourceware.org with SMTP; 13 Oct 2004 04:06:19 -0000 Received: by nondot.org (Postfix, from userid 501) id 7520F17C549; Wed, 13 Oct 2004 00:23:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by nondot.org (Postfix) with ESMTP id 7121424C3BB; Tue, 12 Oct 2004 23:23:22 -0500 (CDT) Date: Wed, 13 Oct 2004 09:18: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/msg00480.txt.bz2 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/