From: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
To: Andrew MacLeod <amacleod@redhat.com>
Cc: Michael Matz <matz@suse.de>, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [ssaupdate] Local dominance info
Date: Fri, 22 Oct 2004 21:33:00 -0000 [thread overview]
Message-ID: <20041022210841.GB1486@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <1098463105.20227.52.camel@pain>
Hello,
> 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.
answer to your questions from my side is "I don't know." I think it
will be useful (obviously :-), but it may turn out that I will be wrong.
Ssaupdate is a development branch, so the way things are done now do not
necessarily have to be the same (or even close to) those that will be in
final version.
Zdenek
next prev parent reply other threads:[~2004-10-22 21:08 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
2004-10-22 21:33 ` Zdenek Dvorak [this message]
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=20041022210841.GB1486@atrey.karlin.mff.cuni.cz \
--to=rakdver@atrey.karlin.mff.cuni.cz \
--cc=amacleod@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=matz@suse.de \
/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).