On Tue, Aug 10, 2021 at 4:03 AM Xionghu Luo via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
> For this case, theorotically I think the master GCC will optimize it to:
>
> invariant;
> for (;;)
> if (unlikely_cond)
> for (;;)
> ;
>
> 'invariant' is moved out of outer loop, but with the patch, it will get:
>
> for (;;)
> if (unlikely_cond)
> {
> invariant;
> for (;;)
> ;
> }
>
> 'invariant' is *cold* for outer loop, but it is still *hot* for inner loop,
> so hoist it out of inner loop, this is exactly what we want, right?
Is relying on absolute numbers really what you want? If the
'unlikely_cond' condition depends on the iteration count of the outer
loop the probability of it being true in each individual iteration can
be low (at least that's how I use unlikely) but the overall
probability of needing the code is higher 1 - (1 - p)^n if 'p' is the
probability of 'unlikely_cond' and 'n' is the number of iterations.
Assuming complete independence of the loop iterations, otherwise it's
rather an upper limit.
At the very least I'd generate code like this:
first = true;
for (;;)
if (unlikely_cond)
{
if (first)
{
invariant;
first = false;
}
for (;;)
;
}
If it's worth hoisting the code the the extra test and flag should be
small in cost in comparison.
If 'unlikely_cond' does not in any way depend on the loop iteration
then I think your code generation is fine.
