From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 05FC83959CBE; Thu, 27 May 2021 18:13:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 05FC83959CBE From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/100781] [12 Regression] Emitted binary code changes when -g is enabled at -O2 Date: Thu, 27 May 2021 18:13:57 +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: X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com 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: Thu, 27 May 2021 18:13:58 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100781 --- Comment #6 from Andrew Macleod --- So the new code base provides a more complete/consistent export list, and m= akes use of imports now. An import is the incoming value which can change an outgoing value. In this particular case we see: : _2 =3D (long int) f$b_17; _3 =3D _2 <=3D e_12(D); h_13 =3D (int) _3; i_14 =3D (int) d_10(D); _5 =3D h_13 >=3D i_14; n_15 =3D (int) _5; if (h_13 < i_14) goto ; [INV] else goto ; [INV] : // predicted unlikely by goto predictor. // predicted unlikely by goto predictor. if (d_10(D) !=3D 0) goto ; [INV] else goto ; [INV] We look at more of these names than we use to, and f$b_17 is now taken into account. bb3 has a back edge from bb9, so we do a little back edge tracking earlier than we use to. Long story short: During the initial traversal, none of the other names in= the block have yet been fully fleshed out when we arrive back at bb3 from the bottom, so the propagation engine uses global values as an initial value. In particular, we use h_13 which has none, so defaults to VARYING. And in "= if h_13 < i_14", that gives us nothing for d_10. however, we later process h_13 =3D (int)_3, and discover it is actually [0,= 1] since _3 is a boolean. We propagate this new [0,1] value, but since it isnt in the dependency chain for d_10, we never re-evaluate d_10. Previously, the first time we evaluate d_10 we see that the edge 3->4 requi= res=20=20 [0,1] < i_14 to be true, which means i_14 =3D [1, +INF] which also means th= at d_10 is non-zero and we fold the condition. The next round of GORI code I'm about to check in makes it fair straightfor= ward to grab an initial value for h_13 even if it hasn't been fully evaluated ye= t.. so instead of VARYING, we'll get the [0,1] range for h_13, and everything w= ill return to the way it was. There is more update/propagation/ordering stuff to come, but I suspect the forthcoming changes will resolve most of these sorts of issues.=