On Wed, 29 Jun 2016, Jan Hubicka wrote:

> > +  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?

I don't think so, you'd have to compare against type_max (nit is
"typeless").

Rihcard.

> > 
> > scev provides scev_direction for this (of course we don't have the chrec
> > anymore here).
> 
> Good, thanks!
> 
> Honza
> 
> 

-- 
Richard Biener <rguent...@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Reply via email to