public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/21829] [4.1/4.2 Regression] missed jump threading after unroller Date: Thu, 09 Feb 2006 03:20:00 -0000 [thread overview] Message-ID: <20060209031959.19753.qmail@sourceware.org> (raw) In-Reply-To: <bug-21829-6528@http.gcc.gnu.org/bugzilla/> ------- Comment #4 from law at redhat dot com 2006-02-09 03:19 ------- I'll note this really isn't a jump threading issue. This is a fundamental weakness in a dominator based optimizer vs a truly global optimizer. What we've got is a block which looks something like this: # u_18 = PHI <u_13(4), u_26(3)>; <L1>:; D.1528_10 = u_18 % 2; if (D.1528_10 == 1) goto <L2>; else goto <L3>; Note carefully that this block is at a dominance frontier (thus the PHI node). At a dominance frontier, a dominator walk does _not_ guarantee that the CFG parents are visited before the node itself. ie, we may visit this block before its CFG parents. That is in fact precisely what happens. Thus we do not discover that u_13 and u_26 both have the value 1 until after we have processed this block. Possible solutions: 1. Iterating DOM. I don't want to do that. 2. Run CCP before DOM. It's something I've pondered, mostly because I want to remove constant propagation from DOM. Compile-time issues worry me. 3. Simple constant/copy propagation in the renaming phase. I've always been a fan of this to avoid clutter in the IL, but I've been overruled on this as a design decision. 4. Somehow arrange to sort the et-tree dominance information so that we visit immediate descendants of a CFG node which are dominated by the node before visiting more distant CFG descendants. This could be horribly ugly. 5. Somehow get really really smart in the block duplication code and arrange for it to propagate constants. I've pondered this, but I don't think it's really that feasible both from a design and implementation standpoint. 6. Post-dom cleanup phase using worklists seeded by degenerate PHI nodes to identify statements that can be simplified as a result of discovery of the degenerate PHI. [Would replace the mini-copyprop pass we do after DOM. ] I suspect #2 or #6 are the most likely long term solutions. jeff -- law at redhat dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
next prev parent reply other threads:[~2006-02-09 3:20 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-21829-6528@http.gcc.gnu.org/bugzilla/> 2005-10-29 15:52 ` [Bug tree-optimization/21829] [4.1 " pinskia at gcc dot gnu dot org 2005-10-30 23:32 ` pinskia at gcc dot gnu dot org 2006-02-09 3:20 ` law at redhat dot com [this message] 2006-02-11 0:59 ` [Bug tree-optimization/21829] [4.1/4.2 " pinskia at gcc dot gnu dot org 2006-02-28 20:39 ` mmitchel at gcc dot gnu dot org 2006-03-21 5:09 ` law at redhat dot com 2006-03-21 5:10 ` law at redhat dot com 2006-03-22 11:14 ` richard dot guenther at gmail dot com 2006-03-22 14:01 ` law at redhat dot com 2006-03-22 15:06 ` richard dot guenther at gmail dot com 2006-03-22 15:36 ` law at redhat dot com 2006-03-28 19:14 ` law at redhat dot com 2006-03-30 17:15 ` law at redhat dot com
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=20060209031959.19753.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: linkBe 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).