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 ...

  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: 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).