This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Can we speed up the gcc_target structure?
- From: Chris Lattner <sabre at nondot dot org>
- To: Richard Henderson <rth at redhat dot com>
- Cc: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>,<ian at wasabisystems dot com>, <gcc at gcc dot gnu dot org>,"Joseph S. Myers" <jsm at polyomino dot org dot uk>
- Date: Sun, 18 Jan 2004 16:37:22 -0600 (CST)
- Subject: Re: Can we speed up the gcc_target structure?
Richard Henderson wrote:
> On Sun, Jan 18, 2004 at 09:14:14PM +0000, Joseph S. Myers wrote:
> > When --enable-intermodule is used, does (or should) the compiler
> > manage to detect which parts of the target structure are in fact
> > constant (even without constifying)?
LLVM is very good at this kind of stuff.
> However, that sort of optimization requires that you see the *entire*
> program, not just large parts of it, as with the current intermodule
> code. So I expect this sort of thing is relatively far away.
This is not really true. At some point, the structure needs to be marked
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.
Note that it is quite possible that the user would like to run the
internalize pass _before_ the whole program is available, for example, to
prune the public symbols exposed by a library.
> 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. A
compiler _very rarely_ has the entire program to analyze, and must
therefore be able to handle the fact that there is external code that can
access program structures (e.g., there can be precompiled libraries (ie,
libc, libm), dynamically loaded libraries (plugins), etc).
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.
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/