public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew MacLeod <amacleod@redhat.com>
To: Michael Matz <matz@suse.de>
Cc: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [ssaupdate] Local dominance info
Date: Fri, 22 Oct 2004 17:05:00 -0000	[thread overview]
Message-ID: <1098463105.20227.52.camel@pain> (raw)
In-Reply-To: <Pine.LNX.4.58.0410221809130.32225@wotan.suse.de>

On Fri, 2004-10-22 at 12:18, Michael Matz wrote:
> Hi,
> 
> On Wed, 20 Oct 2004, Andrew MacLeod wrote:
> 
> > > > 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. 
> > > 
> > > Still you would need some mechanism to update things when statements are
> > > inserted, so this would make things only more complicated.
> > 
> > and what wrong with the local_dom_insert_after() and
> > local_dom_insert_before() which call the bsi routines? It looks pretty
> > trivial to do that,  then the info only exists and is maintained when
> > you want it.
> 
> But then you have to ask yourself everytime you add stmts if you want to 
> use these or the normal inserters.  And what about common code which 
> inserts statements?  Do we need two versions of them too?
> 
> Generally I think there should be exactly one interface to do something 
> (inserting stmts), so if maintaining this local numbering doesn't cost 
> much it would be much cleaner to do this, instead of relying on special 
> case code.
> 
> Why exactly would you like to have this keeping of information be factored 
> out?
> 

the claim is that it is cheap. I claim it will have a cost, perhaps it
is small most of the time, but there is bound to be pathological cases
which do have an impact.

> > I don't see any reason why it should be kept up to date all the time
> > when virtually no-one else cares about it.
> 
> Cleanlyness of interfaces?  Less potential for funny bugs because the 
> wrong inserters were used by some common code?

It depends. I've seen no reason for it. If it turns out that having it
present *will* make a different in updating ssa on the fly, thats
different. I've seen no argument why 70 other optimizations should keep
the information up to date when they dont care about it.

The general renamer has to go through all the basic blocks *anyway* in
order to calculate live-on-entry, so it seems pretty easy to do that
local numbering on the fly since you are making a pass the the IL
anyway.

If there is a more iterative into-ssa solution that can make use of this
info and doesnt have to make a pass through the IL, then thats an
arguement for it.  If there is a reason to keep it up to date other than
that, perhaps that is an argument too. 

So far all Ive seen/heard is keeping the information up to date doesnt
cost a lot, but I see few passes have a use for it.  Tell me how useful
it is, and why its better than calculating it on the fly when you need
it and maybe I am convinced. 

Andrew





  reply	other threads:[~2004-10-22 16:38 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
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 [this message]
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=1098463105.20227.52.camel@pain \
    --to=amacleod@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=matz@suse.de \
    --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).