public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rakdver at atrey dot karlin dot mff dot cuni dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/21356] [4.1 Regression] Dominance error after aggressive dead code elimination (cd_dce)
Date: Thu, 07 Jul 2005 06:57:00 -0000	[thread overview]
Message-ID: <20050707065729.11519.qmail@sourceware.org> (raw)
In-Reply-To: <20050503114028.21356.loki@gcc.gnu.org>


------- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz  2005-07-07 06:57 -------
Subject: Re:  [4.1 Regression] Dominance error after aggressive dead code elimination (cd_dce)

Hello,

> On Tue, 2005-07-05 at 23:29 -0600, Jeffrey A Law wrote:
> > DCE in aggressive mode sometimes is able to remove control structures
> > and thus edge from the CFG.  Sometimes removal of edges from the CFG
> > changes the dominator tree, but we make no attempt to actually keep
> > the dominators up-to-date.
> > 
> > In this testcase failure to keep the dominators up-to-date leads to
> > a checking failure.  This is trivially addressed by arranging for the
> > dominators to be recomputed if we remove edges from the CFG.  An
> > enterprising individual might be able to incrementally update the
> > dominators,
> 
> Uh, we have code to incrementally update the dominators.
> Just use iterate_fix_dominators 

note however that to use it you must precisely know the set of basic
blocks whose dominators may change (which may or may not be the case
with CDDCE, I haven't thought about it), and the set should rather be
small -- iterate_fix_dominators is O(n^3) in the size of the set.

All in all, if the changes to cfg are indeed rare (which they should be,
given that the problem remained unnoticed so far), just having the
dominators to be recomputed is much easier and safer.

Zdenek


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21356


  parent reply	other threads:[~2005-07-07  6:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-03 11:40 [Bug middle-end/21356] New: " loki at gcc dot gnu dot org
2005-05-03 16:00 ` [Bug tree-optimization/21356] [4.1 Regression] " pinskia at gcc dot gnu dot org
2005-07-06 13:23 ` pinskia at gcc dot gnu dot org
2005-07-06 14:06 ` dberlin at dberlin dot org
2005-07-07  6:57 ` rakdver at atrey dot karlin dot mff dot cuni dot cz [this message]
2005-07-08 20:53 ` dnovillo at gcc dot gnu dot org
2005-07-08 21:01 ` dnovillo at gcc dot gnu dot org
2005-07-09 17:35 ` cvs-commit at gcc dot gnu dot org
2005-07-09 17:38 ` dnovillo at gcc dot gnu dot org

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=20050707065729.11519.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).