public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/56264] [4.8 Regression] ICE in check_loop_closed_ssa_use, at  tree-ssa-loop-manip.c:557
Date: Mon, 11 Feb 2013 10:00:00 -0000	[thread overview]
Message-ID: <bug-56264-4-delEatjdZS@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-56264-4@http.gcc.gnu.org/bugzilla/>


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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-11 10:00:18 UTC ---
unswitching makes the formerly irreducible inner loop reducible on one
path (cfgcleanup makes this loop appear).  As we are in the loop optimizer
block we are supposed to be in loop-closed SSA.  Now we only mark
a single block as changed (bb 7, the loop header of the newly recognized
inner loop).  rewrite_into_loop_closed_ssa functions in the way that
it only scans changed_bbs for out-of-def-loop _uses_.  I don't see how
that can catch all changes detected by (even former) fix_loop_structure
which marks blocks as changed whose loop depth changes (that is, if a
definition block changes its loop depth but the use block does not,
like in this case, we fail to fixup loop-closed SSA form).  Not sure if
"no new loops are discovered" excluded this possibility in the old scheme.

Now, the block with the use that needs a loop-closed PHI node at the exit
of the newly discovered loop isn't changed in any way (nor is the exit block).
That said - I still fail to see the logic of the old computation of
"changed-blocks" in fix_loop_structure.  I'd said we need to re-scan
all loop blocks of loops we exit to from loops that have 'changed blocks'.
And maybe all loop blocks we may exit from to a loop that has 'changed blocks'.

Hmmmm.


  parent reply	other threads:[~2013-02-11 10:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-09 12:09 [Bug tree-optimization/56264] New: " antoine.balestrat at gmail dot com
2013-02-09 12:15 ` [Bug tree-optimization/56264] " mpolacek at gcc dot gnu.org
2013-02-09 13:37 ` [Bug tree-optimization/56264] [4.8 Regression] " mpolacek at gcc dot gnu.org
2013-02-10 12:21 ` rguenth at gcc dot gnu.org
2013-02-11 10:00 ` rguenth at gcc dot gnu.org [this message]
2013-02-11 10:28 ` rguenth at gcc dot gnu.org
2013-02-11 15:08 ` rguenth at gcc dot gnu.org
2013-02-11 15:10 ` rguenth at gcc dot gnu.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=bug-56264-4-delEatjdZS@http.gcc.gnu.org/bugzilla/ \
    --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).