public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Chris Lattner <sabre@nondot.org>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: Richard Henderson <rth@redhat.com>,
	"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?
Date: Sun, 18 Jan 2004 22:40:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0401181657240.18812-100000@nondot.org> (raw)
In-Reply-To: <20040118223317.GE11268@atrey.karlin.mff.cuni.cz>

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?

> 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?

> > 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.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

  reply	other threads:[~2004-01-18 22:40 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-18 22:18 Chris Lattner
2004-01-18 22:33 ` Jan Hubicka
2004-01-18 22:40   ` Chris Lattner [this message]
2004-01-18 22:48     ` Jan Hubicka
2004-01-18 22:50       ` Chris Lattner
2004-01-18 23:27         ` Jan Hubicka
2004-01-18 23:34           ` Jakub Jelinek
2004-01-19  1:36           ` Chris Lattner
2004-01-18 22:42   ` Joseph S. Myers
2004-01-18 22:44     ` Chris Lattner
2004-01-18 22:36 ` Richard Henderson
2004-01-18 22:42   ` Chris Lattner
  -- strict thread matches above, loose matches on Subject: below --
2004-01-19 23:48 Richard Kenner
2004-01-19 23:42 Richard Kenner
2004-01-19 23:46 ` Zack Weinberg
2004-01-19 21:25 Richard Kenner
2004-01-19 23:36 ` Zack Weinberg
2004-01-19 19:05 Richard Kenner
2004-01-19 21:15 ` Zack Weinberg
2004-01-19 18:18 Richard Kenner
2004-01-19 18:26 ` Zack Weinberg
2004-01-19 11:51 Richard Kenner
2004-01-19 12:01 ` Richard Guenther
2004-01-19 20:02   ` Richard Henderson
2004-01-19 14:16 ` Robert Dewar
2004-01-19 18:03 ` Zack Weinberg
2004-01-18  8:37 Ian Lance Taylor
2004-01-18  9:03 ` Zack Weinberg
2004-01-18 14:09   ` Ian Lance Taylor
2004-01-18 22:25     ` Zack Weinberg
2004-01-19  0:53       ` Ian Lance Taylor
2004-01-19  1:18       ` Geoff Keating
2004-01-18 11:30 ` Joseph S. Myers
2004-01-18 13:58 ` Kaveh R. Ghazi
2004-01-18 19:54   ` Ian Lance Taylor
2004-01-18 20:10     ` Richard Henderson
2004-01-18 20:17       ` Ian Lance Taylor
2004-01-18 21:14   ` Joseph S. Myers
2004-01-18 22:05     ` Richard Henderson
2004-01-18 22:22       ` Jan Hubicka
2004-01-18 22:37         ` Richard Henderson
2004-01-19 19:33           ` DJ Delorie
2004-01-19 20:41             ` Richard Henderson
2004-01-19  1:12 ` Geoff Keating
2004-01-19 13:51   ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0401181657240.18812-100000@nondot.org \
    --to=sabre@nondot.org \
    --cc=gcc@gcc.gnu.org \
    --cc=ghazi@caip.rutgers.edu \
    --cc=hubicka@ucw.cz \
    --cc=ian@wasabisystems.com \
    --cc=jsm@polyomino.org.uk \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).