public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew MacLeod <amacleod@redhat.com>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: Diego Novillo <dnovillo@redhat.com>,
	Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>,
	gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: [tree-ssa] Lazy updating of stmt operands
Date: Tue, 09 Dec 2003 14:30:00 -0000	[thread overview]
Message-ID: <1070979982.17702.2610.camel@p4> (raw)
In-Reply-To: <200312072241.38969.s.bosscher@student.tudelft.nl>

On Sun, 2003-12-07 at 16:41, Steven Bosscher wrote:
> On Sunday 07 December 2003 18:29, Diego Novillo wrote:
> > > > tree-dfa.c:compute_immediate_uses()
> > >
> > > Which needs to pass through every single statement in the program. Not
> > > really terribly efficient.
> >
> > *shrug*, it's used by SSA-CCP.  Since def-use edges are only needed by
> > some passes, I don't think it would be worth our while trying to
> > maintain them in get_stmt_operands.
> 
> There are going to be more passes that need immediate uses.  Even a simple 
> pass to kill redundant PHIs (say, after unswitching a loop) will have to go 
> over _all_ statements to get the immediate uses of one or two statements.  It 
> would be really nice if there were some way to keep this information 
> up-to-date at all times...

So use get_immidiate_uses() which does what is required on demand, and
if we discover its a serious performance issue down the road, it ought
to be easy enough to change. The interface is abstracted out already.
since operands are cached, a pass through the IL is actually pretty
cheap. Its nothing like the expense of a pass through rtl.

The effort and memory required to keep this information up to date
throughout all compilations would not be insignificant, and until it is
demonstrated that its a win to do so, I wouldn't want to keep it around
all the time.

CCP uses the information, and one of the big compile time and memory
savings on that pass was to optimize the immediate_uses code to only
build it for SSA_NAMEs which we actually cared about. It was a
significant memory hit to build it and have it around for all stmts. 

It would also be possible down the road, if it is an issue, to maintain
the immediate uses information only for as long as it is required. 
Ie, get_stmt_operands could update the immediate_uses info if its
present and we want to keep it up to date. Then if you have a string of
optimizations that want the information, you can keep it up to date
automatically. 

I'd wait until we measure a performance need to do this however. 

Andrew

  reply	other threads:[~2003-12-09 14:26 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-07 16:22 Zdenek Dvorak
2003-12-07 17:14 ` Diego Novillo
2003-12-07 17:28   ` Zdenek Dvorak
2003-12-07 17:36     ` Diego Novillo
2003-12-07 18:09       ` Zdenek Dvorak
2003-12-11 19:39         ` law
2003-12-07 22:20       ` Steven Bosscher
2003-12-09 14:30         ` Andrew MacLeod [this message]
2003-12-09 20:40           ` Zdenek Dvorak
2003-12-11 19:41           ` law
2003-12-11 19:38       ` law
2003-12-11 19:52         ` Zdenek Dvorak
2003-12-11 22:36         ` Zdenek Dvorak
2003-12-11 23:34           ` Andrew MacLeod
2003-12-15 19:10           ` Andrew MacLeod
2003-12-15 19:19             ` Zdenek Dvorak
2003-12-15 20:55               ` Andrew MacLeod
2003-12-15 21:06                 ` Zdenek Dvorak
2003-12-15 21:39                   ` Andrew MacLeod
2003-12-15 21:49                     ` Zdenek Dvorak
2003-12-15 22:04                       ` Andrew MacLeod
2003-12-15 22:39                         ` law
2003-12-17  4:56                       ` law
2003-12-16 23:32               ` Andrew MacLeod
2003-12-17  0:09                 ` Zdenek Dvorak
2003-12-17  0:21                   ` Andrew MacLeod
2003-12-17  3:28                 ` law
2003-12-15 19:28             ` Diego Novillo
2003-12-11 22:31 Chris Lattner
2003-12-12  3:14 ` law
2003-12-12  3:58   ` Chris Lattner
2003-12-12 19:25     ` Andrew MacLeod
2003-12-12 19:42       ` Zdenek Dvorak
2003-12-12 19:45         ` Andrew MacLeod
2003-12-12 19:54           ` Chris Lattner
2003-12-12 19:55             ` Andrew MacLeod
2003-12-12 21:26               ` Diego Novillo
2003-12-12 19:57       ` Chris Lattner
2003-12-13 16:02         ` Andrew MacLeod
2003-12-14  3:39           ` Chris Lattner
2003-12-15 23:41           ` law
2003-12-16  6:02             ` Andrew MacLeod
2003-12-15 20:47 Chris Lattner

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=1070979982.17702.2610.camel@p4 \
    --to=amacleod@redhat.com \
    --cc=dnovillo@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=rakdver@atrey.karlin.mff.cuni.cz \
    --cc=s.bosscher@student.tudelft.nl \
    /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).