From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 005E13858C53; Fri, 2 Dec 2022 08:19:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 005E13858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669969192; bh=sEMjKAo7nCu0wRKjq74yGiMr0bENWDV+gds2nyT20lM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=yqJZ27mDmDLajYi8b76ss7Sgsn6/qPNKLltPk2sPzu9VCyOLKKTJUXTkcULrMhUVI c07dgMJVnZBjDJwSTJBpHEla1Vaa0YEurpOQIUiYWj7+rgN1E0AdPcV/9WNFJL/NFQ EEZwgIVDKhT/GooCuyUOk2RBjUOjFwtecXA1Uu7c= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f Date: Fri, 02 Dec 2022 08:19:51 +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.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth 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.3 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107833 --- Comment #11 from Richard Biener --- (In reply to Andrew Pinski from comment #10) > (In reply to Jakub Jelinek from comment #9) > > Wasn't this discussed in the past in other PRs? Whether uninitialized = vars > > mean anything or anything but same value each time a SSA_NAME initializ= ed to > > it is used? >=20 > I think you are talking about PR 100810 and the discussions around the pa= tch > that fixed that. Yep, it looks exactly like such a case - IVOPTs is replacing 'h' in the second inner loop with an expression based on 'i' and places the computation of 'h' before the early exit (because that's where the original 'h' IV PHI is defined). I think the placement doesn't make a difference but replacing the loop exit test does? Anyway, GCC doesn't ensure stability of uninitialized values which means any expressions derived become indeterminate, i_1(D) - i_1(D) isn't guaranteed to be zero if you obfuscate that a bit. That puts the burden on compiler passes to never introduce new intermediate values since whether any of the expression participating values are not initialized might only become visible later. OK, maybe that's too restrictive, but I certainly warned that the fix in PR100810 is going to be whack-a-mole playing. Here we have marking _19 as maybe-undef marking _44 as maybe-undef because of _19 but then we have [local count: 118111601]: # a.6_39 =3D PHI <_8(13), a.6_32(11)> # h_41 =3D PHI # i_44 =3D PHI g =3D 0;=20 _1 =3D i_44 % 2; f.1_2 =3D f;=20 if (a.6_39 < h_41) note how the use of i was hoisted which makes the /* Look for any uses of the maybe-unused SSA_NAME that dominates the block that reaches the incoming block corresponding to the PHI arg in which it is mentioned. That means we can assume the SSA_NAME is defined in that path, so we only mark a PHI result as maybe-undef if we find an unused reaching SSA_NAME. */ int idx =3D phi_arg_index_from_use (use_p); basic_block bb =3D gimple_phi_arg_edge (phi, idx)->src; if (ssa_name_any_use_dominates_bb_p (var, bb)) continue; logic fail. It's invariant motion that moves this use (I think we have a duplicate issue with regarding to -Wuninitialized for this kind of transform): _1 =3D i_44 % 2; invariant up to level 2, cost 20. ... Moving statement _1 =3D i_44 % 2; (cost 20) out of loop 2. We could try to use the same mark_ssa_maybe_undefs in invariant motion but it might not be a trivial exercise. I also question sustainability of how we extend exploitation of undefinedness in GCC ... :/=