From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17416 invoked by alias); 2 Dec 2004 18:23:48 -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 17359 invoked from network); 2 Dec 2004 18:23:44 -0000 Received: from unknown (HELO mail2.codesourcery.com) (66.160.135.55) by sourceware.org with SMTP; 2 Dec 2004 18:23:44 -0000 Received: (qmail 20243 invoked from network); 2 Dec 2004 18:23:10 -0000 Received: from support.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.10) by mail2.codesourcery.com with SMTP; 2 Dec 2004 18:23:10 -0000 Received: (qmail 27797 invoked from network); 2 Dec 2004 18:23:10 -0000 Received: from localhost (HELO ?192.168.0.100?) (mitchell@127.0.0.1) by mail.codesourcery.com with SMTP; 2 Dec 2004 18:23:10 -0000 Message-ID: <41AF5D87.3010507@codesourcery.com> Date: Thu, 02 Dec 2004 18:23:00 -0000 From: Mark Mitchell Organization: CodeSourcery, LLC User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) MIME-Version: 1.0 To: Joe Buck CC: "Joseph S. Myers" , Ian Lance Taylor , gcc@gcc.gnu.org Subject: Re: Compiler uses a lot of memory for large initialized arrays References: <20041202101803.A18628@synopsys.com> In-Reply-To: <20041202101803.A18628@synopsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00143.txt.bz2 Joe Buck wrote: > If we successfully reach the end of the initializer without anything evil > like the above case, then append the temp file to the assembly output. > Otherwise, go back and do it in memory. I can't fathom why we are considering things like this. Like anything else, we should try to use an efficient representation, which we are not, at present. We should fix that. But why should we go beyond that, jumping through complicated hoops to support initialization of gigabytes of data? We don't jump through these kinds of hoops to support compilation of functions with millions of lines of code, or translation units with millions of functions. I think it's perfectly reasonable to run out of memory processing a truly huge array -- provided that the compiler is being sensible about its internal representation. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304