From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5456 invoked by alias); 2 Dec 2004 17:39:16 -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 5442 invoked from network); 2 Dec 2004 17:39:12 -0000 Received: from unknown (HELO mail2.codesourcery.com) (66.160.135.55) by sourceware.org with SMTP; 2 Dec 2004 17:39:12 -0000 Received: (qmail 18802 invoked from network); 2 Dec 2004 17:39:11 -0000 Received: from support.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.10) by mail2.codesourcery.com with SMTP; 2 Dec 2004 17:39:11 -0000 Received: (qmail 22777 invoked from network); 2 Dec 2004 17:39:11 -0000 Received: from localhost (HELO ?192.168.0.100?) (mitchell@127.0.0.1) by mail.codesourcery.com with SMTP; 2 Dec 2004 17:39:11 -0000 Message-ID: <41AF5335.50509@codesourcery.com> Date: Thu, 02 Dec 2004 17:39:00 -0000 From: Mark Mitchell Organization: CodeSourcery, LLC User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) MIME-Version: 1.0 To: Peter Barada CC: nathan@codesourcery.com, richard.guenther@gmail.com, stevenb@suse.de, joseph@codesourcery.com, ian@wasabisystems.com, gcc@gcc.gnu.org Subject: Re: Compiler uses a lot of memory for large initialized arrays References: <425929.1102007117190.SLOX.WebMail.wwwrun@extimap.suse.de> <84fc9c000412020912298ed15c@mail.gmail.com> <41AF4E27.7070606@codesourcery.com> <20041202172949.9C1119842C@baradas.org> In-Reply-To: <20041202172949.9C1119842C@baradas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00138.txt.bz2 Peter Barada wrote: >>>Or can't we seek in the asm output and overwrite previously written values? >>>Might be slow, though. >> >>Even if that were sensible, where will we remember the file offsets >>of each and every element :) I think overwriting stuff in the assembler is a horrible idea. I also think that trying to acheive 2.95.3 memory usage for huge arrays is foolish. Since then, we've deliberately substantially increased the amount of memory we need for lots of things: function-at-a-time is more expensive than statement-at-a-time, and now we're unit-at-a-time for many compilations -- as we should be. Most compilers suck up lots of memory with vast arrays; I don't think we need to be different, alleged regression or not. However, the C++ front end (and perhaps the C front end) do some pretty silly stuff when contstructing the arrays. I believe that when I analyzed this, I determined that there were factor-of-eight sorts of improvements possible. That's what I think we should fix. We've already got some of that, in that, for example, Nathan's changed things so that we share integer constants. The next major step is to change CONSTRUCTOR to use an array, rather than a linked list, of elements for CONSTRUCTOR_ELTS. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304