From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A45D53858402; Tue, 28 Sep 2021 10:20:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A45D53858402 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/101641] Bogus redundant store removal Date: Tue, 28 Sep 2021 10:20:29 +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: 11.1.1 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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: Tue, 28 Sep 2021 10:20:29 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101641 --- Comment #7 from Richard Biener --- Wow, and this time it's even combine coming into play! (insn 10 9 11 2 (set (reg/v:DI 82 [ xy ]) (mem/j:DI (reg/v/f:DI 86 [ pu ]) [2 pu_6(D)->y+0 S8 A64])) "t.i":12= :8 76 {*movdi_internal} (nil)) (insn 11 10 12 2 (set (mem/j:DI (reg/v/f:DI 86 [ pu ]) [2 pu_6(D)->x+0 S8 A= 64]) (reg/v:DI 82 [ xy ])) "t.i":13:9 76 {*movdi_internal} (expr_list:REG_DEAD (reg/v/f:DI 86 [ pu ]) (expr_list:REG_DEAD (reg/v:DI 82 [ xy ]) (nil)))) Trying 10 -> 11: 10: r82:DI=3D[r86:DI] 11: [r86:DI]=3Dr82:DI REG_DEAD r86:DI REG_DEAD r82:DI Failed to match this instruction: (set (mem/j:DI (reg/v/f:DI 86 [ pu ]) [2 pu_6(D)->x+0 S8 A64]) (mem/j:DI (reg/v/f:DI 86 [ pu ]) [2 pu_6(D)->y+0 S8 A64])) allowing combination of insns 10 and 11 original costs 4 + 4 =3D 8 replacement cost 4 deferring deletion of insn with uid =3D 10. modifying insn i3 11: [r86:DI]=3D[r86:DI] REG_DEAD r86:DI deferring rescan insn with uid =3D 11. Trying 4 -> 11: 4: r86:DI=3Dr91:DI REG_DEAD r91:DI 11: [r86:DI]=3D[r86:DI] REG_DEAD r86:DI Failed to match this instruction: (set (mem/j:DI (reg:DI 91) [2 pu_6(D)->x+0 S8 A64]) (mem/j:DI (reg:DI 91) [2 pu_6(D)->y+0 S8 A64])) allowing combination of insns 4 and 11 original costs 4 + 4 =3D 8 replacement cost 4 deferring deletion of insn with uid =3D 4. modifying insn i3 11: [r91:DI]=3D[r91:DI] REG_DEAD r91:DI deferring rescan insn with uid =3D 11. deleting noop move 11 somewhere inside combine we'd have to realize that this isn't a noop move and then maybe not allow the combination in the first place since it isn't recognizable? That is, somehow we must anticipate the removal, I suppose it is via /* Recognize all noop sets, these will be killed by followup pass. */ if (insn_code_number < 0 && GET_CODE (pat) =3D=3D SET && set_noop_p (pat)) insn_code_number =3D NOOP_MOVE_INSN_CODE, num_clobbers_to_add =3D 0; where set_noop_p for two MEMs simply dispatches to rtx_equal_p && !side_effects_p. Note on RTL we see that we cannot rely on MEM_ALIAS_SET but have to use MEM_EXPR to conservatively assess that the access is _not_ through a union ... (or as said we could annotate the alias set entry as to belonging to a union). In the end how we handle TBAA and unions might not be the very best way (but I can't offer something better yet).=