Re: [Patch][RFC?] Re-guess probability when unswitch hoists a condition before the loop [PR126664]

On Fri, 7 Aug 2026, Tobias Burnus wrote:

> This is for https://gcc.gnu.org/PR126664 where an invariant condition in
> a loop is estimated to have 0% and 100% edge probabilities. One can argue
> about the 0% vs. 1000% in the loop, but, in any case, after hoisting the
> condition, the probability is surely wrong as 41% and 59% are expected.
> 
> The 0% leads to count 0, which prevents vectorization; with vectorization,
> the mentioned code in the PR runs, respectively, 9 or 40 times faster on
> an AMD GPU with OpenMP and OpenACC offloading. (cf. PR)
> 
> * * *
> 
> For the question about the 100% and 0% see Richard's comment in the PR
> in general and, additionally, his question whether the following is
> a bug - fix by:
>           update_profile (epath, EDGE_SUCC (rd->dup_blocks[count], 0),
> -                         path_out_count, path_out_count);
> +                         path_in_count, path_out_count);

this didn't actually help ...

> * * *
> 
> Back to the attached patch:
> 
> The patch is based on the assumption that the probability can be
> different when moved outside of the loop - and just re-guesses it
> makes sense, which yields the expected 41% and 59% edge probabilities.
> 
> Is the patch OK – or at least like the right approach?

unconditionally re-guessing seems overly conservative when the
unswitched condition is always executed in the loop.

-  scale_loop_frequencies (loop, then_scale);
-  scale_loop_frequencies (nloop, else_scale);
+  if (then_scale.initialized_p () && else_scale.initialized_p ())
+    {
+      scale_loop_frequencies (loop, then_scale);
+      scale_loop_frequencies (nloop, else_scale);
+    }
+  else
+    {
+      edge te = EDGE_SUCC (cond_bb, 0);
+      edge ee = EDGE_SUCC (cond_bb, 1);
+      scale_loop_frequencies (loop, te->probability);
+      scale_loop_frequencies (nloop, ee->probability);
+    }

doesn't the 2nd hunk always work? (are you sure of the
first/second edge going to the respective loops?)


> [At least for now, i.e. if it turned out that with other fixes,
> it is no longer needed, then it could be still reverted.]
> 
> 
> And: Any suggestion how to create a testcase for it?
> 
> I could package the testcase from the PR and check in the 'unswitch'
> tree dump for the following:
> 
>   if (l_params$hphb_187 < 0.0)
>     goto <bb 17>; [0.00%]
>   else
>     goto <bb 36>; [100.00%]
> 
> But not with 0% and 100% but with a probability between 10% and
> 90% for either edge. - Any better idea?
> 
> Tobias
> 
> 

-- 
Richard Biener <[email protected]>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Jochen Jaser, Andrew McDonald, Abhinav Puri; (HRB 36809, AG Nuernberg)