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/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu since r14-4777-g88c27070c25309 Date: Wed, 15 Nov 2023 10:36:21 +0000 [thread overview] Message-ID: <bug-112282-4-OeuqJAZ6aT@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-112282-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112282 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> --- So I can cut off bitfield lowering completely, the important part is that we version the loop and thus try to BB vectorize the loop header (yeah, we don't BB vectorize the whole body - or rather, we think the header _is_ the fully body). But a key to the failure seems to be that we BB vectorize the unrolled for (; ac < 1; ac++) for (k = 0; k < 9; k++) am[k] = 0; and doing that not from SLP but from loop vectorization of if-conversion versioned (but otherwise unchanged) loop. It's also solely triggered by unrolling the 'z' loop. Disabling all following passes will still reproduce it. The region VN triggered by ifconversion/vectorization/unrolling isn't needed either (I disabled it). Maybe PR111572 is related (but it doesn't change unrolling and disabling ch_vect doesn't avoid the problem). Unrolling does Analyzing # of iterations of loop 2 exit condition [23, + , 4294967295] != 0 bounds on difference of bases: -23 ... -23 result: # of iterations 23, bounded by 23 Removed pointless exit: if (ivtmp_1055 != 0) because we computed loop->nb_iterations_upper_bound to 21: Statement (exit)if (ivtmp_1055 != 0) is executed at most 23 (bounded by 23) + 1 times in loop 2. Induction variable (int) 21 + -1 * iteration does not wrap in statement _4 = ~u.13_485; in loop 2. Statement _4 = ~u.13_485; is executed at most 21 (bounded by 21) + 1 times in loop 2. Induction variable (int) -21 + 1 * iteration does not wrap in statement _19 = u.13_485 + 1; in loop 2. Statement _19 = u.13_485 + 1; is executed at most 23 (bounded by 23) + 1 times in loop 2. Reducing loop iteration estimate by 1; undefined statement must be executed at the last iteration. we're SCEV analyzing _4 here, computing {21, +, -1}_2 and VRP1 computed [irange] int [0, +INF] somehow for it. u.13_485 has a global range of [-2147483647, 1], so obviously it must infer sth else here somehow and wrongly so? That very same def also appears with plain -O3. Global Exported: _4 = [irange] int [0, +INF] Hmm. We have Folding statement: _64 = ~u.13_20; Global Exported: _64 = [irange] int [-2, -1] MASK 0x1 VALUE 0xfffffffe Folding statement: _4 = ~u.13_20; Global Exported: _4 = [irange] int [0, +INF] but the if-conversion pass hoists that before the .LOOP_VECTORIZED properly resetting flow-sensitive info on stmts hoisted fixes this. Meh. Premature duplicate transforms ...
next prev parent reply other threads:[~2023-11-15 10:36 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-10-29 22:39 [Bug tree-optimization/112282] New: wrong code (generated code hangs) at -O3 on x86_64-linux-gnu zhendong.su at inf dot ethz.ch 2023-10-29 22:41 ` [Bug tree-optimization/112282] [14 Regression] " pinskia at gcc dot gnu.org 2023-10-29 22:51 ` pinskia at gcc dot gnu.org 2023-10-30 0:40 ` sjames at gcc dot gnu.org 2023-10-30 0:41 ` sjames at gcc dot gnu.org 2023-10-30 1:28 ` sjames at gcc dot gnu.org 2023-10-30 1:48 ` pinskia at gcc dot gnu.org 2023-10-30 1:53 ` pinskia at gcc dot gnu.org 2023-10-30 3:49 ` [Bug tree-optimization/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu since r14-4777-g88c27070c25309 sjames at gcc dot gnu.org 2023-10-30 9:13 ` tnfchris at gcc dot gnu.org 2023-10-30 14:21 ` rguenth at gcc dot gnu.org 2023-10-30 20:21 ` avieira at gcc dot gnu.org 2023-10-31 9:12 ` avieira at gcc dot gnu.org 2023-10-31 9:12 ` avieira at gcc dot gnu.org 2023-11-14 14:48 ` rguenth at gcc dot gnu.org 2023-11-15 10:36 ` rguenth at gcc dot gnu.org [this message] 2023-11-15 10:56 ` rguenth at gcc dot gnu.org 2023-11-15 12:12 ` cvs-commit at gcc dot gnu.org 2023-11-15 12:12 ` rguenth at gcc dot gnu.org 2023-11-16 7:05 ` cvs-commit 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-112282-4-OeuqJAZ6aT@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).