From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CBA193857804; Fri, 8 Oct 2021 12:18:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CBA193857804 From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102385] [12 Regression] ICE: in single_pred_edge, at basic-block.h:350 under "-O2 -fno-toplevel-reorder -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-loop-ivcanon -fpredictive-commoning" since r12-2429-g62acc72a957b5614 Date: Fri, 08 Oct 2021 12:18:46 +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: ice-on-valid-code, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rsandifo 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, 08 Oct 2021 12:18:46 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102385 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:0ee3dc6052361290c92bba492cc0a9e556b31055 commit r12-4250-g0ee3dc6052361290c92bba492cc0a9e556b31055 Author: Richard Sandiford Date: Mon Oct 4 23:55:43 2021 +0100 loop: Fix profile updates after unrolling [PR102385] In g:62acc72a957b5614 I'd stopped the unroller from using an epilogue loop in cases where the iteration count was known to be a multiple of the unroll factor. The epilogue and non-epilogue cases still shared this (preexisting) code to update the edge frequencies: basic_block exit_bb =3D single_pred (loop->latch); new_exit =3D find_edge (exit_bb, rest); new_exit->probability =3D profile_probability::always () .apply_scale (1, new_est_niter + 1); [etc] But of course (in hindsight) that only makes sense for the epilogue case, where we've already moved the main loop's exit edge to be a sibling of the latch edge. For the non-epilogue case, the exit edge stays (and needs to stay) in its original position. I don't really understand what the code is trying to do for the epilogue case. It has: /* Ensure that the frequencies in the loop match the new estimated number of iterations, and change the probability of the new exit edge. */ profile_count freq_h =3D loop->header->count; profile_count freq_e =3D (loop_preheader_edge (loop))->count (); if (freq_h.nonzero_p ()) { ... scale_loop_frequencies (loop, freq_e.probability_in (freq_h)); } Here, freq_e.probability_in (freq_h) is freq_e / freq_h, so for the header block, this has the effect of: new header count =3D freq_h * (freq_e / freq_h) i.e. we say that the header executes exactly as often as the preheader edge, which would only make sense if the loop never iterates. Also, after setting the probability of the nonexit edge (correctly) to new_est_niter / (new_est_niter + 1), the code does: scale_bbs_frequencies (&loop->latch, 1, prob); for this new probability. I think that only makes sense if the nonexit edge was previously unconditional (100%). But the code carefully preserved the probability of the original exit edge when creating the new one. All I'm trying to do here though is fix the mess I created and get the probabilities right for the non-epilogue case. Things are simpler there since we don't have to worry about loop versioning. Hopefully the comments explain the approach. The function's current interface implies that it can cope with multiple exit edges and that the function only needs the iteration count relative to one of those edges in order to work correctly. In practice that's not the case: it assumes there is exactly one exit edge and all current callers also ensure that the exit test dominates the latch. I think the function is easier to follow if we remove the implied generality. gcc/ PR tree-optimization/102385 * predict.h (change_edge_frequency): Declare. * predict.c (change_edge_frequency): New function. * tree-ssa-loop-manip.h (tree_transform_and_unroll_loop): Remove edge argument. (tree_unroll_loop): Likewise. * gimple-loop-jam.c (tree_loop_unroll_and_jam): Update accordin= gly. * tree-predcom.c (pcom_worker::tree_predictive_commoning_loop): Likewise. * tree-ssa-loop-prefetch.c (loop_prefetch_arrays): Likewise. * tree-ssa-loop-manip.c (tree_unroll_loop): Likewise. (tree_transform_and_unroll_loop): Likewise. Use single_dom_exit to retrieve the exit edges. Make all the old profile update co= de conditional on !single_loop_p -- the case it was written for -- and use a different approach for the single-loop case. gcc/testsuite/ * gcc.dg/pr102385.c: New test.=