From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CECD4385117A; Thu, 15 Sep 2022 11:26:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CECD4385117A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663241188; bh=2kcy+KAqxd2lGTJR8ffhhsCaZwL3sZpYVya2hEygoHk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=W4YehLtoE8eGxZRbrVFxbdzuwfcOBE21ZYdKmvAyJQXdCsojOZh1jm+suS5hFp4/U k/+kbWTKcJQrrLHjjbO9ugeNaDh9WWxcRCTB4IA6R7ms37GV15Hgfoup5ndEpC7qfs /Bdqjp9XYKY8j0kfcovFs5aSSGR8j+FOvXKoPic4= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/106922] [12/13 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE Date: Thu, 15 Sep 2022 11:26:28 +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.2.1 X-Bugzilla-Keywords: diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106922 --- Comment #4 from Richard Biener --- Created attachment 53577 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D53577&action=3Dedit testcase for missed PRE on trunk Here's one. So the issue is that PRE EXP_GEN now contains exp_gen[10] :=3D { {component_ref,mem_ref<0B>,addr_expr<&external>}@.MEM_31 (00= 09) } for the block [local count: 97603128]: # .MEM_31 =3D VDEF <.MEM_55> internal =3D{v} {CLOBBER}; # VUSE <.MEM_32> _10 =3D MEM[(struct optional_base *)&external].m_initialized; if (_10 !=3D 0) instead of the one with last_vuse .MEM_45. That in turn causes prune_clobbered_mems to prune the expression from ANTIC_OUT of BB 9 which has a 9->10 edge removing the incentive to perform FRE on this value inside the loop. prune_clobbered_mems does this because if (ref->vuse) { gimple *def_stmt =3D SSA_NAME_DEF_STMT (ref->vuse); if (!gimple_nop_p (def_stmt) && ((gimple_bb (def_stmt) !=3D block && !dominated_by_p (CDI_DOMINATORS, block, gimple_bb (def_stmt))) || (gimple_bb (def_stmt) =3D=3D block && value_dies_in_block_x (expr, block)))) to_remove =3D i; where block =3D=3D BB9 so the dominance test fails. The dominance test sho= uld be redundant (unless we have translated something over a backedge!?) but it really shows the issue that we fail to record the memory expression with the correct VUSE into EXP_GEN and fail to adjust the VUSE when translating from ANTIC_OUT to ANTIC_IN as well. When we'd do all this "correctly", then we'd get a) a ton more hashtable entries with questionable value, b) the dominance test will never fail. By that reasoning a cheaper fix should be to instead perform the value_dies_in_block_x when a dominance check cannot elide it. There's a possible latent issue with virtual operands PHI translation over backedges then though. The safest thing would be to eventually force a set of the virtual operand when any virtual PHI is on the edge we are translating over - we are actually doing this but the no-PHI-nodes optimization in phi_translate_set defeats the intent of adjusting to BB_LIVE_VOP_ON_EXIT that translate_vuse_through_block performs and its simple check of BB equality means we don't fixup later either. Fixing that spot in the simplistic way as well (rather than consistently handling the virtual operand everywhere) fixes the observed bogus diagnostic.=