From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-89247-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 11280 invoked by alias); 18 Jan 2004 22:36:47 -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 11273 invoked from network); 18 Jan 2004 22:36:46 -0000
Received: from unknown (HELO frothingslosh.sfbay.redhat.com) (66.187.237.200)
  by sources.redhat.com with SMTP; 18 Jan 2004 22:36:46 -0000
Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1])
	by frothingslosh.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id i0IMajOG014971;
	Sun, 18 Jan 2004 14:36:45 -0800
Received: (from rth@localhost)
	by frothingslosh.sfbay.redhat.com (8.12.8/8.12.8/Submit) id i0IMajMS014969;
	Sun, 18 Jan 2004 14:36:45 -0800
X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f
Date: Sun, 18 Jan 2004 22:36:00 -0000
From: Richard Henderson <rth@redhat.com>
To: Chris Lattner <sabre@nondot.org>
Cc: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>, ian@wasabisystems.com,
   gcc@gcc.gnu.org, "Joseph S. Myers" <jsm@polyomino.org.uk>
Subject: Re: Can we speed up the gcc_target structure?
Message-ID: <20040118223645.GA14927@redhat.com>
Mail-Followup-To: Richard Henderson <rth@redhat.com>,
	Chris Lattner <sabre@nondot.org>,
	"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>, ian@wasabisystems.com,
	gcc@gcc.gnu.org, "Joseph S. Myers" <jsm@polyomino.org.uk>
References: <Pine.LNX.4.44.0401181630170.17710-100000@nondot.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0401181630170.17710-100000@nondot.org>
User-Agent: Mutt/1.4i
X-SW-Source: 2004-01/txt/msg01202.txt.bz2

On Sun, Jan 18, 2004 at 04:37:22PM -0600, Chris Lattner wrote:
> > One possibility is a switch that says "except for main, nothing
> > outside these files reference any of the symbols herein defined."
> > That might get you the same effect as whole-program optimization
> > without having to have extra info about external runtime libraries.
> 
> This is _extremely_ dangerous, and in practice, cannot be done.
[...]
> The nice thing about LLVM using the internalize pass is that if it is used
> incorrectly, a program will not link.

We're talking about the *exact* same transformation.


r~