public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "amker.cheng at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug regression/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4 Date: Tue, 11 Mar 2014 11:34:00 -0000 [thread overview] Message-ID: <bug-60363-4-8TCXIjQCPa@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-60363-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363 --- Comment #6 from bin.cheng <amker.cheng at gmail dot com> --- After investigation, I think the root cause is: For given mergephi2 dump (before vrp), there are latch(bb13) and header(bb14) of a loop: <bb 13>: # changed_18 = PHI <changed_26(12), changed_1(7), changed_1(8), changed_1(9), changed_1(11)> <bb 14>: # changed_1 = PHI <changed_18(13), 0(2)> # kill_elt_4 = PHI <kill_elt_3(13), kill_elt_7(D)(2)> if (a_elt_9(D) != 0B) goto <bb 3>; else goto <bb 15>; The latch is removed by the bogus patch, and the code turns into: <bb 14>: # changed_1 = PHI <changed_1(7), 0(2), changed_26(12), changed_1(11), changed_1(9), changed_1(8)> # kill_elt_4 = PHI <kill_elt_3(7), kill_elt_7(D)(2), kill_elt_3(12), kill_elt_3(11), kill_elt_3(9), kill_elt_3(8)> if (a_elt_9(D) != 0B) goto <bb 3>; else goto <bb 15>; Since VRP requires LOOP_HAVE_SIMPLE_LATCH, it will be initialized into: <bb 14>: # changed_19 = PHI <changed_1(7), changed_1(22), changed_26(12), changed_1(11), changed_1(9)> # kill_elt_18 = PHI <kill_elt_3(7), kill_elt_33(22), kill_elt_32(12), kill_elt_32(11), kill_elt_32(9)> <bb 17>: # changed_1 = PHI <changed_19(14), 0(2)> # kill_elt_4 = PHI <kill_elt_18(14), kill_elt_7(D)(2)> if (a_elt_9(D) != 0B) goto <bb 24>; else goto <bb 15>; After all works in vrp (including jump threading), the code is transformed into below form: <bb 18>: # kill_elt_2 = PHI <kill_elt_10(5), kill_elt_14(4)> if (kill_elt_2 != 0B) goto <bb 6>; else goto <bb 21>; <bb 21>: goto <bb 27>; ... <bb 14>: # changed_19 = PHI <changed_1(7), changed_1(22), changed_26(12), changed_1(11), changed_1(9), changed_1(27), changed_1(29)> # kill_elt_18 = PHI <kill_elt_3(7), 0B(26), kill_elt_3(12), kill_elt_3(11), kill_elt_3(9), kill_elt_3(27), kill_elt_3(29)> <bb 17>: # changed_1 = PHI <changed_19(14), 0(2)> # kill_elt_4 = PHI <kill_elt_18(14), kill_elt_7(D)(2)> if (a_elt_9(D) != 0B) goto <bb 24>; else goto <bb 15>; ... <bb 26>: goto <bb 14>; <bb 27>: # kill_elt_41 = PHI <0B(21)> if (b_elt_11(D) != 0B) goto <bb 26>; else goto <bb 14>; When trying to remove bb26, it finds out bb27 is pred of both bb26 and bb14, then checks whether the phi args are consistent for both edges (<26, 14> and <27, 14>). Apparently "0B(26)" != "kill_elt_3(27)", resulting in keeping bb27. Actually, kill_elt_3(27) equals to "0", because of check condition in bb18. So this might be a missed opportunity in vrp?
next prev parent reply other threads:[~2014-03-11 11:34 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-02-28 1:31 [Bug regression/60363] New: " hp at gcc dot gnu.org 2014-02-28 1:32 ` [Bug regression/60363] " hp at gcc dot gnu.org 2014-02-28 9:18 ` rguenth at gcc dot gnu.org 2014-03-09 13:31 ` amker.cheng at gmail dot com 2014-03-09 13:36 ` amker.cheng at gmail dot com 2014-03-09 15:00 ` amker.cheng at gmail dot com 2014-03-11 9:16 ` amker.cheng at gmail dot com 2014-03-11 11:34 ` amker.cheng at gmail dot com [this message] 2014-03-12 10:27 ` amker.cheng at gmail dot com 2014-03-31 9:29 ` [Bug tree-optimization/60363] " rguenth at gcc dot gnu.org 2014-03-31 9:39 ` amker.cheng at gmail dot com 2014-03-31 13:26 ` law at redhat dot com 2014-04-01 12:41 ` rguenth at gcc dot gnu.org 2014-04-22 11:35 ` [Bug tree-optimization/60363] [4.9/4.10 " jakub at gcc dot gnu.org 2014-05-06 7:16 ` amker.cheng at gmail dot com 2014-05-06 8:25 ` 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-60363-4-8TCXIjQCPa@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: 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).