Re: [PATCH][RFC] Fix PR39233, SCEV, IVOPTs and overflow

[Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>]

Hi,

> > > > > Comments?  Or even ideas (ideas suitable for 4.4 - I have enough
> > > > > for later, if you have spare time ask me)?
> > > > 
> > > > what is the purpose of the change you propose for simple_iv?  
> > > > The result of simple_iv is guaranteed not to wrap only if iv->no_overflow is true
> > > > (so simple_iv may return a description of a wrapping iv in type for that
> > > > the overflow is undefined).  Hence this change seems wrong:
> > > > 
> > > > > !   /* If we folded casts and the result is a type where overflow is
> > > > > !      undefined the IV may not be simple as it can have introduced
> > > > > !      undefined overflow that wasn't there before.  */
> > > > > !   if (!iv->no_overflow
> > > > > !       && folded_casts
> > > > > !       && (TYPE_OVERFLOW_UNDEFINED (type)
> > > > > ! 	  || POINTER_TYPE_P (type)))
> > > > > !     return false;
> > > > 
> > > > I guess there is an error at some place that uses of simple_iv, assuming
> > > > a different semantics,
> > > 
> > > The "iv->no_overflow" flag is lost once the IV is put into the IL.  In
> > > the case in question IVOPTs puts in a IV which type has undefined overflow
> > > semantics (and iv->no_overflow is not set), later VRP based on that
> > > undefinedness optimizes the code, which is wrong (well, the IV 
> > > substitution is wrong).
> > 
> > so ivopts should be fixed.
> 
> An alternate patch would be to just do the above check at the callsites
> of simple_iv in ivopts.  Or do you have another idea where to fix this
> in ivopts?

ivopts generally try to avoid this kind of troubles by performing all
the calculations in unsigned integers, only casting the result to the
final type; probably a cast is missing somewhere,

Zdenek