public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103721] [12 regression] wrong code generated for loop with conditional since r12-4790-g4b3a325f07acebf4 Date: Tue, 18 Jan 2022 04:02:45 +0000 [thread overview] Message-ID: <bug-103721-4-xrkgmeFM5t@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103721-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721 Jeffrey A. Law <law at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at gcc dot gnu.org --- Comment #4 from Jeffrey A. Law <law at gcc dot gnu.org> --- But what doesn't make any sense here is the folding in this block: <bb 9> [local count: 1073741824]: # searchVolume_5 = PHI <searchVolume_11(8), world_7(D)(2)> # currentVolume_6 = PHI <currentVolume_8(8), 0(2)> _2 = searchVolume_5 != currentVolume_6; _3 = searchVolume_5 != 0; _4 = _2 & _3; if (_4 != 0) goto <bb 3>; [89.00%] else goto <bb 7>; [11.00%] In fold_using_range::range_of_range_op we have: (gdb) p debug_tree (op1) <ssa_name 0x7ffff77fef30 type <integer_type 0x7ffff780e5e8 int sizes-gimplified public SI size <integer_cst 0x7ffff77f3f90 constant 32> unit-size <integer_cst 0x7ffff77f3fa8 constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type 0x7ffff780e5e8 precision:32 min <integer_cst 0x7ffff77f3f48 -2147483648> max <integer_cst 0x7ffff77f3f60 2147483647> pointer_to_this <pointer_type 0x7ffff7816a80>> visited var <var_decl 0x7ffff7a12cf0 searchVolume> def_stmt searchVolume_5 = PHI <searchVolume_11(8), world_7(D)(2)> version:5> $113 = void (gdb) p debug_tree (op2) <ssa_name 0x7ffff77fef78 type <integer_type 0x7ffff780e5e8 int sizes-gimplified public SI size <integer_cst 0x7ffff77f3f90 constant 32> unit-size <integer_cst 0x7ffff77f3fa8 constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type 0x7ffff780e5e8 precision:32 min <integer_cst 0x7ffff77f3f48 -2147483648> max <integer_cst 0x7ffff77f3f60 2147483647> pointer_to_this <pointer_type 0x7ffff7816a80>> visited var <var_decl 0x7ffff7a12d80 currentVolume> def_stmt currentVolume_6 = PHI <currentVolume_8(8), 0(2)> version:6> $114 = void (gdb) p rel $115 = EQ_EXPR If I'm reading the code correctly I think that means that the ranger has determined that _5 and _6 are equal. But I don't see how it can possibly make that determination with this CFG: int f (int world) { int currentVolume; int searchVolume; int ipos.0_1; _Bool _2; _Bool _3; _Bool _4; ;; basic block 2, loop depth 0 ;; pred: ENTRY goto <bb 9>; [100.00%] ;; succ: 9 ;; basic block 3, loop depth 1 ;; pred: 9 ipos.0_1 = ipos; if (ipos.0_1 != 0) goto <bb 8>; [50.00%] else goto <bb 4>; [50.00%] ;; succ: 8 ;; 4 ;; basic block 4, loop depth 1 ;; pred: 3 ;; succ: 8 ;; basic block 8, loop depth 1 ;; pred: 4 ;; 3 # searchVolume_11 = PHI <1(4), 0(3)> # currentVolume_8 = PHI <searchVolume_5(4), searchVolume_5(3)> ;; succ: 9 ;; basic block 9, loop depth 1 ;; pred: 8 ;; 2 # searchVolume_5 = PHI <searchVolume_11(8), world_7(D)(2)> # currentVolume_6 = PHI <currentVolume_8(8), 0(2)> _2 = searchVolume_5 != currentVolume_6; _3 = searchVolume_5 != 0; _4 = _2 & _3; if (_4 != 0) goto <bb 3>; [89.00%] else goto <bb 7>; [11.00%] ;; succ: 3 ;; 7 ;; basic block 7, loop depth 0 ;; pred: 9 return currentVolume_6; ;; succ: EXIT } This feels like it's got to be a problem in the equivalence handling -- it's largely outside the threader. My recollection of equivalences in loops is that they're exceedingly hard to get correct once you follow the backedge -- particularly since you have to invalidate some equivalences once you traverse that backedge. Finding the set that needed to be invalidated was expensive and the book keeping turned out to be too hard to do reliably so I ripped it all out. How does equivalence handling in the Ranger world work once you traverse the backedge of a loop?
next prev parent reply other threads:[~2022-01-18 4:02 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-14 22:19 [Bug tree-optimization/103721] New: [12 regression] wrong code generated for loop with conditional (jump threading?) sss@li-snyder.org 2021-12-14 22:21 ` [Bug tree-optimization/103721] " pinskia at gcc dot gnu.org 2021-12-14 23:03 ` pinskia at gcc dot gnu.org 2021-12-15 11:27 ` [Bug tree-optimization/103721] [12 regression] wrong code generated for loop with conditional since r12-4790-g4b3a325f07acebf4 marxin at gcc dot gnu.org 2022-01-04 11:16 ` rguenth at gcc dot gnu.org 2022-01-06 20:13 ` amacleod at redhat dot com 2022-01-18 4:02 ` law at gcc dot gnu.org [this message] 2022-01-18 18:49 ` amacleod at redhat dot com 2022-01-19 12:44 ` aldyh at gcc dot gnu.org 2022-01-19 16:40 ` aldyh at gcc dot gnu.org 2022-01-19 16:58 ` amacleod at redhat dot com 2022-01-19 22:51 ` law at gcc dot gnu.org 2022-01-20 0:10 ` amacleod at redhat dot com 2022-01-20 11:13 ` aldyh at gcc dot gnu.org 2022-01-20 11:14 ` aldyh at gcc dot gnu.org 2022-01-20 13:28 ` aldyh at gcc dot gnu.org 2022-01-20 14:12 ` amacleod at redhat dot com 2022-01-21 10:19 ` cvs-commit at gcc dot gnu.org 2022-01-21 10:30 ` aldyh 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-103721-4-xrkgmeFM5t@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).