From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23709 invoked by alias); 18 Jan 2004 22:48:35 -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 23702 invoked from network); 18 Jan 2004 22:48:34 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 18 Jan 2004 22:48:34 -0000 Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107]) by nikam.ms.mff.cuni.cz (Postfix) with SMTP id 3C6384DF25; Sun, 18 Jan 2004 23:48:36 +0100 (CET) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Sun, 18 Jan 2004 23:48:38 +0100 Date: Sun, 18 Jan 2004 22:48:00 -0000 From: Jan Hubicka To: Chris Lattner Cc: Jan Hubicka , Richard Henderson , "Kaveh R. Ghazi" , ian@wasabisystems.com, gcc@gcc.gnu.org, "Joseph S. Myers" Subject: Re: Can we speed up the gcc_target structure? Message-ID: <20040118224838.GL5119@kam.mff.cuni.cz> References: <20040118223317.GE11268@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2004-01/txt/msg01210.txt.bz2 > On Sun, 18 Jan 2004, Jan Hubicka wrote: > > > as having internal linkage. In LLVM, this is accomplished with the > > > "internalize" pass, which by default marks all symbols internal if the > > > linked program contains a main (ie, this does not happen for libraries). > > > This change enables a _lot_ of interprocedural optimizations that would > > > not be safe to perform otherwise. Of course the internalize pass can be > > > completely disabled, or enabled for a list of symbols as needed. > > > > In my prototype unit-at-a-time code I have either the default mode, > > where all external symbols are just external and -fwhole-program mode > > where all symbols that do have deifnitions are considered internal > > except for main and symbols marked by "used" attribute. > > But they get emitted to the executable as external? If you mark no symbols via special attribute, only main should be external. If you mark more, you get more. > > > I suppose this is mostly equivalent to what LLVM have except for the > > fact that list of symbols with external linkage is boundled in the > > source itself, instead of being in separate file. Do you have any > > experience with the separate file having considerable benefits? > > I'm not sure if I understand what you mean here, can you please clarify? You mentioned that instead of using attribute in the source file, you get list of functions. From here the lists are comming? > > > > The nice thing about LLVM using the internalize pass is that if it is used > > > incorrectly, a program will not link. If you use a "whole program" > > > compiler incorrectly, it will be silently misoptimized, which IMHO is > > > _much_ worse. > > > > My plan is to make all symbols that are considered local static so it > > will elliminate this problem. > > Ok, but you should at least think about adding support for programs that > (for example) dynamically load shared objects that call back into the main > program. People will get unhappy if 'gimp' doesn't work in this mode, for > example. I expect people to just mark the interface functions via the attribute. Honza > > -Chris > > -- > http://llvm.cs.uiuc.edu/ > http://www.nondot.org/~sabre/Projects/