diff mbox series

ipa-cp: One more safe_add (PR 97816)

Message ID ri6o8k1xj37.fsf@suse.cz
State New
Headers show
Series ipa-cp: One more safe_add (PR 97816) | expand

Commit Message

Martin Jambor Nov. 13, 2020, 5:27 p.m. UTC
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  <mjambor@suse.cz>

	PR ipa/97816
	* ipa-cp.c (value_topo_info<valtype>::propagate_effects): Use
	safe_add instead of a simple addition.
---
 gcc/ipa-cp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Jan Hubicka Nov. 13, 2020, 5:29 p.m. UTC | #1
> 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  <mjambor@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
>
diff mbox series

Patch

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)