From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-113752-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 14416 invoked by alias); 4 May 2005 18:01:45 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 14108 invoked from network); 4 May 2005 18:01:41 -0000
Received: from unknown (HELO vaxjo.synopsys.com) (198.182.60.75)
  by sourceware.org with SMTP; 4 May 2005 18:01:41 -0000
Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170])
	by vaxjo.synopsys.com (Postfix) with ESMTP
	id 52AD1DC7B; Wed,  4 May 2005 11:01:40 -0700 (PDT)
Received: from piper.synopsys.com (localhost [127.0.0.1])
	by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id LAA14472;
	Wed, 4 May 2005 11:01:39 -0700 (PDT)
Received: from piper.synopsys.com (localhost [127.0.0.1])
	by piper.synopsys.com (8.12.10/8.12.3) with ESMTP id j44I1djW028584;
	Wed, 4 May 2005 11:01:39 -0700
Received: (from jbuck@localhost)
	by piper.synopsys.com (8.12.10/8.12.10/Submit) id j44I1cgv028582;
	Wed, 4 May 2005 11:01:38 -0700
X-Authentication-Warning: piper.synopsys.com: jbuck set sender to Joe.Buck@synopsys.com using -f
Date: Wed, 04 May 2005 18:11:00 -0000
From: Joe Buck <Joe.Buck@synopsys.COM>
To: Ian Lance Taylor <ian@airs.com>
Cc: "H. J. Lu" <hjl@lucon.org>, Andrew Haley <aph@redhat.com>,
	Alexandre Oliva <aoliva@redhat.com>,
	David Edelsohn <dje@watson.ibm.com>, Andreas Schwab <schwab@suse.de>,
	Richard Earnshaw <rearnsha@gcc.gnu.org>,
	Andrew Pinski <pinskia@physics.uc.edu>,
	Paul Koning <pkoning@equallogic.com>, s.bosscher@student.tudelft.nl,
	gcc@gcc.gnu.org, matt@3am-software.com, cow@compsoc.man.ac.uk
Subject: Re: GCC 4.1: Buildable on GHz machines only?
Message-ID: <20050504180138.GB28410@synopsys.com>
References: <20050428164727.GB30649@synopsys.com> <200504281654.j3SGs0D27158@makai.watson.ibm.com> <oracncw0a1.fsf@livre.redhat.lsd.ic.unicamp.br> <20050503220342.GA23969@synopsys.com> <17016.41624.799846.161219@cuddles.cambridge.redhat.com> <20050504134157.GA5261@lucon.org> <20050504160005.GB26103@synopsys.com> <20050504161719.GA7542@lucon.org> <20050504162944.GA28196@synopsys.com> <m3br7rkkl9.fsf@gossamer.airs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m3br7rkkl9.fsf@gossamer.airs.com>
User-Agent: Mutt/1.4.1i
X-SW-Source: 2005-05/txt/msg00190.txt.bz2

On Wed, May 04, 2005 at 12:43:46PM -0400, Ian Lance Taylor wrote:
> At present the linker provides command line options --no-keep-memory
> and --reduce-memory-overheads to significantly reduce the amount of
> memory required during the link.
> 
> It should be possible in principle to partially adapt to available
> memory based on, e.g., physmem_total.  The linker could keep track of
> how much memory it has allocated via bfd_alloc and bfd_malloc.  If
> that total gets to be 75% of physmem_total, or something like that,
> the linker could switch to --no-keep-memory.
> 
> Unfortunately the decisions made by --reduce-memory-overhead apply at
> the start of the link.  At that time it is difficult to tell how much
> memory will be needed.

If the number gets much above 100%, it would probably be faster for the linker
to quit and start over than to proceed, and such an approach wouldn't be
hard to implement.