> Hi,
>
> The new behavior of safe_add triggered an ICE because of one use where
> it had not been used instead of a simple addition. I'll fix it with the
> following obvious patch so that periodic benchmarkers can continue
> working because a proper fix (see below) will need a review.
>
> The testcase showed me, however, that we can propagate time and cost
> from one lattice to another more than once even when that was not the
> intent. I'll address that as a follow-up after I verify it does not
> affect the IPA-CP heuristics too much or change the corresponding
> params accordingly.
>
> Bootstrapped and tested on x86_64-linux.
>
> Thanks,
>
> Martin
>
>
> gcc/ChangeLog:
>
> 2020-11-13 Martin Jambor <mjam...@suse.cz>
>
> PR ipa/97816
> * ipa-cp.c (value_topo_info<valtype>::propagate_effects): Use
> safe_add instead of a simple addition.
Seems OK. I wonder if we can't just stop propagation earlier? Does it
really make sense to propagate such a large vlaues? Don't we have some
cap on how much size we permit?
thanks!
Honza
> ---
> gcc/ipa-cp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index f29f2164f4e..c3ee71e16e1 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -3873,7 +3873,8 @@ value_topo_info<valtype>::propagate_effects ()
> for (val = base; val; val = val->scc_next)
> {
> time = time + val->local_time_benefit + val->prop_time_benefit;
> - size = safe_add (size, val->local_size_cost + val->prop_size_cost);
> + size = safe_add (size, safe_add (val->local_size_cost,
> + val->prop_size_cost));
> }
>
> for (val = base; val; val = val->scc_next)
> --
> 2.28.0
>
