From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29890 invoked by alias); 18 Jan 2008 19:07:50 -0000 Received: (qmail 29871 invoked by uid 22791); 18 Jan 2008 19:07:48 -0000 X-Spam-Check-By: sourceware.org Received: from mail6.primus.ca (HELO mail-07.primus.ca) (216.254.141.173) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jan 2008 19:07:25 +0000 Received: from ottawa-hs-209-217-122-41.s-ip.magma.ca ([209.217.122.41] helo=[192.168.8.125]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFwYf-0004MS-00; Fri, 18 Jan 2008 14:07:17 -0500 Message-ID: <4790F8F1.40805@ellipticsemi.com> Date: Sun, 20 Jan 2008 19:08:00 -0000 From: Tom St Denis User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Andrew Haley CC: Tony Wetmore , Alejandro Pulver , gcc-help@gcc.gnu.org Subject: Re: Reducing compilation memory usage References: <20080117140156.201451e8@deimos.mars.bsd> <20080117170952.7d569374@deimos.mars.bsd> <478FAAF9.9000301@solipsys.com> <20080117180809.2f5db118@deimos.mars.bsd> <479080DD.8070608@redhat.com> <20080118123926.6fe1feea@deimos.mars.bsd> <4790CCF2.3080305@solipsys.com> <4790F090.3080606@redhat.com> In-Reply-To: <4790F090.3080606@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: elp125 - ottawa-hs-209-217-122-41.s-ip.magma.ca ([192.168.8.125]) [209.217.122.41] X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00184.txt.bz2 Andrew Haley wrote: > Tony Wetmore wrote: >> Alejandro Pulver wrote: >> >> RAM! Of course we could make gcc more economical, and >> >> we could somewhat reduce memory usage, but you're asking >> >> for something really hard. >> > >> > I wasn't asking to change the program, I was just asking >> > if there is an already existing option. >> >> I think Andrew may have meant that you are asking GCC to do something >> really hard, to optimize a single function that is so large. And >> asking the compiler to do something that hard has a price -- it >> requires lots of memory, as you have discovered. > > I was saying exactly that, thank you for clarifying. > > The thing to realize is that it is really hard to do a great job of > optimizing > huge functions. So, it's quite likely that gcc will do a better job of > optimizing a bunch of small functions, with well-contained locality of > variables, > than one huge function. > > OK, so you will have the overhead of a function call. But on most > architectures > that isn't enormous. Dropping some Friday afternoon pair of cents ... You shouldn't really have large functions unless their machine made anyways. And even then it's best to try and factor them as much as possible. In one of my math libraries I have huge unrolled multipliers, for things like 1024x1024 bit multiplications (on a 32-bit platform that means 1024 MULADD macros). Originally, I had all of the multipliers [different functions] in a single .C file which was machine generated. Later I found GCC performs much better on the same code if I left it one huge function per file. Anyways ... on code that's human-written, you should never really run into any of these sorts of limits. Otherwise, you're not thinking about your design properly. Tom