From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 28C9C3858416; Fri, 22 Oct 2021 11:08:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 28C9C3858416 From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102895] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0) Date: Fri, 22 Oct 2021 11:08:21 +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: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Fri, 22 Oct 2021 11:08:21 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102895 --- Comment #2 from Aldy Hernandez --- (In reply to Richard Biener from comment #1) > There's identical IL before the vrp2 pass (the one after strlen) but on t= he > GCC 11 branch vrp2 eliminates the call to foo while on trunk it does not. >=20 > On the branch VRP registers >=20 > Registering jump thread: (2, 3) incoming edge; (3, 4) normal; >=20 > which elides the call but vrp-thread2 does not do this: >=20 > Registering value_relation (_5 > a.4_4) (bb5) at _5 =3D a.4_4 + 1; > Registering value_relation (_19 > a.4_13) (bb4) at _19 =3D a.4_13 + 1; > [4] Registering jump thread: (2, 3) incoming edge; (3, 4) normal; > Failure in thread_through_loop_header: Cancelling jump thread: (2, 3) > incoming edge; (3, 4) normal; >=20 > on the branch this threading destroys the loop structure It seems there were other threads in play before the loop restriction chang= es went in. In the branch we have: $ gcc a.c -O2 -fdump-tree-all-details -c abulafia:~/bld/t/gcc$ grep thread a.c.* a.c.124t.dom2: Registering jump thread: (10, 5) incoming edge; (5, 12) normal; a.c.124t.dom2: Registering jump thread: (9, 3) incoming edge; (3, 4) norm= al; a.c.189t.dom3: Registering jump thread: (2, 3) incoming edge; (3, 4) norm= al; a.c.192t.vrp2: Registering jump thread: (2, 3) incoming edge; (3, 4) norm= al; DOM2 was getting 2 threads, but in mainline we have: ./cc1 a.c -O2 -fdump-tree-all-details -quiet abulafia:~/bld/t/gcc$ grep thread a.c.* a.c.128t.dom2:Threading through latch before loop opts would create non-emp= ty latch: Cancelling jump thread: (10, 5) incoming edge; (5, 12) normal;=20 a.c.128t.dom2:Path rotates loop: Cancelling jump thread: (9, 3) incoming edge; (3, 4) normal;=20 a.c.193t.dom3: [3] Registering jump thread: (2, 3) incoming edge; (3, 4) normal;=20 a.c.193t.dom3:Failure in thread_through_loop_header: Cancelling jump thre= ad: (2, 3) incoming edge; (3, 4) normal;=20 a.c.197t.vrp-thread2: [4] Registering jump thread: (2, 3) incoming edge; = (3, 4) normal;=20 a.c.197t.vrp-thread2:Failure in thread_through_loop_header: Cancelling ju= mp thread: (2, 3) incoming edge; (3, 4) normal;=20 Those DOM2 threads were cancelled because of the loop restrictions we put i= n.=20 Since jump threads in one pass open the possibilities of further jump threa= ds by other passes, it could be that the missing DOM2 threads are causing VRP2= to miss out. However, vrp-thread2 *does* find and register the path. It's the block cop= ier that is complaining: a.c.197t.vrp-thread2: [4] Registering jump thread: (2, 3) incoming edge; = (3, 4) normal;=20 a.c.197t.vrp-thread2:Failure in thread_through_loop_header: Cancelling ju= mp thread: (2, 3) incoming edge; (3, 4) normal;=20 Note that these "Failure in thread_through_loop_header" messages are new debugging aids in this release, but the cancel_thread was present neverthel= ess. It was just silent. I would guess it's either the missing DOM threads that has cascading effect= s, or something in the block copier (fwd_jt_path_registry::). FWIW, there have been no changes in the block copier in this release.=