In my case this is not exactly what the FIXME in the comment above says. The
count is 0 even before
the initial scaling happens. I hit this case with some changes I'm working on
to enable per-instruction discriminators for AutoFDO.
I looked into saving/restoring the old counts but it would be awkward to do.
The initial scaling happens here:
if (skip_vector)
{
split_edge (loop_preheader_edge (loop));
/* Due to the order in which we peel prolog and epilog, we first
propagate probability to the whole loop. The purpose is to
avoid adjusting probabilities of both prolog and vector loops
separately. Note in this case, the probability of epilog loop
needs to be scaled back later. */
basic_block bb_before_loop = loop_preheader_edge (loop)->src;
if (prob_vector.initialized_p ())
{
scale_bbs_frequencies (&bb_before_loop, 1, prob_vector);
scale_loop_profile (loop, prob_vector, 0);
}
}
The scaling happens before we do the cloning for the epilog so to save/restore
the counts
we would need to maintain a mapping between the original basic blocks and the
cloned basic blocks in the epilog.
I'd like to get my simple fix in since it makes things better even if it
doesn't address the issue mentioned
In the FIXME.
-----Original Message-----
From: Richard Biener <richard.guent...@gmail.com>
Sent: Monday, May 09, 2022 12:42 AM
To: Eugene Rozenfeld <eugene.rozenf...@microsoft.com>; Jan Hubicka
<hubi...@ucw.cz>
Cc: gcc-patches@gcc.gnu.org
Subject: [EXTERNAL] Re: [PATCH] Guard against applying scale with 0 denominator
On Fri, May 6, 2022 at 10:32 PM Eugene Rozenfeld via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Calling count.apply_scale with a 0 denominator causes an assert.
> This change guards against that.
>
> Tested on x86_64-pc-linux-gnu.
>
> gcc/ChangeLog:
> * tree-loop-vect-manip.cc (vect_do_peeling): Guard against applying
> scale with 0 denominator.
> ---
> gcc/tree-vect-loop-manip.cc | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
> index 1d4337eb261..db54ae69e45 100644
> --- a/gcc/tree-vect-loop-manip.cc
> +++ b/gcc/tree-vect-loop-manip.cc
> @@ -2989,10 +2989,11 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> niters, tree nitersm1,
> get lost if we scale down to 0. */
> basic_block *bbs = get_loop_body (epilog);
> for (unsigned int i = 0; i < epilog->num_nodes; i++)
> - bbs[i]->count = bbs[i]->count.apply_scale
> - (bbs[i]->count,
> - bbs[i]->count.apply_probability
> - (prob_vector));
> + if (bbs[i]->count.nonzero_p ())
> + bbs[i]->count = bbs[i]->count.apply_scale
> + (bbs[i]->count,
> + bbs[i]->count.apply_probability
> + (prob_vector));
So exactly what the FIXME in the comment above says happens. It
might be better
to save/restore the old counts if the intent is to get them back. I'm not
exactly sure where the other scaling happens though.
Richard.
> free (bbs);
> }
>
> --
> 2.25.1
