> + if (!get_max_loop_iterations (loop, &nit))
> + /* 10GHz CPU runing one cycle loop will reach 2^60 iterations in 260
> + years. I won't live long enough to be forced to fix the
> + miscompilation. Having the limit here will let us to consider
> + 64bit IVs with base 0 and step 1...16 as non-wrapping which makes
> + niter and ivopts go smoother. */
> + nit = ((widest_int)1 << 60);
>
> I think that's on the border of being acceptable. Consider said loop
> being autoparallelized and run on a PFlop cluster. Please take it out
> for now.
OK, once we will be able to get more than 2^64 iterations in resonable time,
we will need to revisit gcov code ;)
>
> + if (INTEGRAL_TYPE_P (type))
> + {
> + maxt = TYPE_MAX_VALUE (type);
> + mint = TYPE_MIN_VALUE (type);
> + }
> + else
> + {
> + maxt = upper_bound_in_type (type, type);
> + mint = lower_bound_in_type (type, type);
> + }
>
> I think we don't support any non-integral/pointer IVs and thus you
> can simply use
>
> type_min/max = wi::max/min_value (TYPE_PRECISION (type), TYPE_SIGN
> (type));
OK.
>
> + type_min = wi::to_widest (mint);
> + type_max = wi::to_widest (maxt);
> + if ((base_max + step_max * (nit + 1)) > (type_max)
> + || type_min > (base_min + step_min * (nit + 1)))
> + return true;
>
> so I'm not convinced that widest_int precision is enough here. Can't
> you use wide_ints instead of widest_ints and use the wi::add / wi::mult
> overloads which provide the overflow flag? Otherwise do what
> VRP does and use FIXED_WIDE_INT to properly handle __int128_t IVs.
nit is widest_int because, so I suppose first I need to convert it to wide_int
and then do the overflow checks. Do we have narrowing conversion with overflow
flat, too?
>
> scev provides scev_direction for this (of course we don't have the chrec
> anymore here).
Good, thanks!
Honza
