public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Henderson <rth@redhat.com>,
	"Joseph S. Myers" <jsm@polyomino.org.uk>,
	"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>,
	ian@wasabisystems.com, gcc@gcc.gnu.org
Subject: Re: Can we speed up the gcc_target structure?
Date: Sun, 18 Jan 2004 22:22:00 -0000	[thread overview]
Message-ID: <20040118222201.GD11268@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <20040118220522.GA14767@redhat.com>

> 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)?
> 
> I'm certain that it doesn't.
> 
> It's not inconcievable that a compiler could not that there are 
> never any writes to a structure, promote it to readonly, and then
> constant propagate the values out of that structure.
> 
> 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.
> 
> 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.

I do have such prototype of -fwhole-program optimization.  What is
preventing me from putting it into tree-SSA branch is that I don't like
the symbols that are considered local to appear as external symbols in
output object file and I am not sure whether frobbing of TREE_PUBLIC
flag is best idea around.

I also hacked up Makefiles to use it, but with our current way to do IPA
it means that all backend functions are parsed and optimized over and
over for each frontend binary that results in verly long bootstrap times
and memory consumption.

What is preventing us from declaring the structure as constant so we
should get propagation even with current design?

Honza
> 
> 
> 
> r~

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

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
2004-01-18 22:18 Chris Lattner
2004-01-18 22:33 ` Jan Hubicka
2004-01-18 22:40   ` Chris Lattner
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
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-19 18:18 Richard Kenner
2004-01-19 18:26 ` Zack Weinberg
2004-01-19 19:05 Richard Kenner
2004-01-19 21:15 ` Zack Weinberg
2004-01-19 21:25 Richard Kenner
2004-01-19 23:36 ` Zack Weinberg
2004-01-19 23:42 Richard Kenner
2004-01-19 23:46 ` Zack Weinberg
2004-01-19 23:48 Richard Kenner

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=20040118222201.GD11268@atrey.karlin.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc@gcc.gnu.org \
    --cc=ghazi@caip.rutgers.edu \
    --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).