From: Andrew MacLeod <amacleod@redhat.com>
To: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [ssaupdate] Local dominance info
Date: Wed, 20 Oct 2004 13:32:00 -0000 [thread overview]
Message-ID: <1098279112.5695.3918.camel@pain> (raw)
In-Reply-To: <20041019215129.GA29721@atrey.karlin.mff.cuni.cz>
On Tue, 2004-10-19 at 17:51, Zdenek Dvorak wrote:
> Hello,
>
> this patch adds dominance information to statements, i.e. it makes it
> possible to decide whether a statement precedes other one inside a basic
> block without need to scan the whole block.
>
> To enable this, statements inside basic block are numbered (the
> numbering contains holes, so that new statements may be inserted). This
> seems to work good enough (no measurable impact on compile time).
You want to keep and maintain this information all the time?
This strikes me *much* more as a local thing that an individual pass
might be interested in, and so should number the stmt's itself for the
duration of its interest.
I think trying to keep numbered order of stmts within blocks for the
duration of SSA is a very bad idea since most optimizations do not care.
So you have the overhead of making sure that you keep things kosher
everytime you ever move anything. You will always have an end case where
the hole isnt big enough, so you'll have to renumber either the entire
block, or parts of it. This will no doubt happen during an optimization
phase that doesn't care about local numbers.
I can see having an aux field in stmts much like edges do, where an
individual pass can use that field for whatever it want, in your case
for these local dominance numbers. If you wish to maintain these numbers
for a series of optimizations and you are interested in having the
insert routines take care of it for you, then at best I could see
creating local_dom_insert_before(), local_dom_insert_after(), etc which
call the bsi_* insertion routines, and then update your local dominance
info. Then you could use those routine in areas where you care about it
without affecting anyone else. This seems like it ought to be pretty
easy to do since you call setup_local_dom_number() as the last thing
after inserting.
I do not thing this should be part of the generic bsi_* routines.
Andrew
next prev parent reply other threads:[~2004-10-20 13:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-19 21:54 Zdenek Dvorak
2004-10-20 13:32 ` Andrew MacLeod [this message]
2004-10-20 19:35 ` Zdenek Dvorak
2004-10-20 22:26 ` Andrew MacLeod
2004-10-20 22:54 ` Zdenek Dvorak
2004-10-21 3:06 ` Jeffrey A Law
2004-10-22 16:38 ` Michael Matz
2004-10-22 17:05 ` Andrew MacLeod
2004-10-22 21:33 ` Zdenek Dvorak
2004-10-22 21:47 ` Andrew MacLeod
2004-10-21 10:25 ` Paolo Bonzini
2004-10-21 10:53 ` Zdenek Dvorak
2004-10-21 10:54 ` Paolo Bonzini
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=1098279112.5695.3918.camel@pain \
--to=amacleod@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rakdver@atrey.karlin.mff.cuni.cz \
/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).