From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 823BB3858C60; Thu, 7 Oct 2021 16:07:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 823BB3858C60 From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102622] [12 Regression] Wrong code with -O3 for skylake-avx512 and icelake-server by r12-3903 Date: Thu, 07 Oct 2021 16:07:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 16:07:40 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102622 Aldy Hernandez changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amacleod at redhat dot com, | |jakub at gcc dot gnu.org, | |rguenth at gcc dot gnu.org --- Comment #12 from Aldy Hernandez --- I had to download the Intel SDE to reproduce it, but was finally able to na= rrow it down to 4 jump threading paths: ./xg++ -B./ a.c -O3 -L/usr/lib/gcc/x86_64-redhat-linux/11/ -march=3Dskylake-avx512 -fdump-tree-all-details -fdisable-tree-ethread -fdisable-tree-thread1 -fdisable-tree-thread2 -fdisable-tree-thread3 -fdisable-tree-thread4 -fdbg-cnt=3Dregistered_jump_thread:2-4:19-20 $ grep 'thread' a.c.* |grep Registering a.c.113t.vrp-thread1: [2] Registering jump thread: (9, 11) incoming edge;= =20 (11, 10) normal;=20 a.c.113t.vrp-thread1: [4] Registering jump thread: (5, 7) incoming edge; = (7, 8) normal;=20 a.c.197t.vrp-thread2: [19] Registering jump thread: (15, 16) incoming edge= ;=20 (16, 18) normal;=20 a.c.197t.vrp-thread2: [20] Registering jump thread: (21, 16) incoming edge= ;=20 (16, 18) normal;=20 Things start getting challenging after the vectorizer and cunroll run. Such that by vrp-thread2, ranger figures out that the 2->3 edge is unreachable, = _21 must be 0, and shit rolls downhill from there: unsigned long ivtmp.31; short int * vectp_arr_32.21; vector(8) short int * vectp_arr_32.20; unsigned short tmp.19; short int tmp.18; int D.4484; bool var_22_lsm_flag.15; int var_22_lsm.14; int D.4481; bool var_20_lsm_flag.13; int var_20_lsm.12; unsigned int f; int e; short int d; short int _2; unsigned int _3; bool _4; long long int _6; int _7; bool _21; unsigned short ivtmp_24; int _30(D); bool _33; unsigned short ivtmp_41; int _43(D); short int * _55; _64; int _66; unsigned long _74; _75; vector(8) vect_cst__76; void * _81; [local count: 8685306]: _2 =3D (short int) b_15(D); _3 =3D (unsigned int) _2; _4 =3D _3 !=3D 0; _33 =3D _3 < b_15(D); _21 =3D _4 | _33; _64 =3D () _21; _75 =3D -_64; vect_cst__76 =3D {_75, _75, _75, _75, _75, _75, _75, _75}; if (_75 =3D=3D 0) goto ; [100.00%] else goto ; [20.00%] [local count: 1737061]: MEM [(short int *)&arr_32] =3D { 0, 0, 0, 0, 0, 0, = 0, 0 }; [local count: 8685306]: if (_21 !=3D 0) goto ; [50.00%] else goto ; [50.00%] [local count: 2171327]: arr_32[8] =3D 0; [local count: 4342653]: if (_21 !=3D 0) goto ; [50.00%] else goto ; [50.00%] [snip] [snip] The reason ranger concludes that 2->3 is unreachable is from analyzing bloc= k 2: [local count: 8685306]: _2 =3D (short int) b_15(D); _3 =3D (unsigned int) _2; _4 =3D _3 !=3D 0; _33 =3D _3 < b_15(D); _21 =3D _4 | _33; _64 =3D () _21; _75 =3D -_64; vect_cst__76 =3D {_75, _75, _75, _75, _75, _75, _75, _75}; if (_75 =3D=3D 0) goto ; [100.00%] else goto ; [20.00%] On the 2->3 edge, _75 =3D=3D -1 because this is a 1-bit signed integer. So= lving back we have: _75 =3D - _64; =3D=3D> [-1,-1] =3D -_64; -1 for a 1-bit signed integer is TYPE_MIN_VALUE, and NEG(TYPE_MIN_VALUE) is unrepresentable. So, _75 cannot be -1, thus the edge is unexecutable. Questions: a) Is -(-1) representable in 1-bit signed? b) Could we somehow avoid creating the 1-bit signed in the vectorizer, since they are a source of endless exception? Thanks.=