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

Richard Guenther rguenther@suse.de
Sat Feb 21 11:14:00 GMT 2009


On Sat, 21 Feb 2009, Zdenek Dvorak wrote:

> 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,

I don't think it's that easy.  The induction variable in question
shows up in the list of induction variables and is chosen as the
one to base everything else off, including the exit test (which
ends up being the problematic use).  Note that it is a pointer
induction variable that ends up overflowing and the exit test
being against (void *)-1 - this is because ivcanon reverses
the loop.  So I tried to fix this by making this pointer induction
variable not a candidate.

Can you have a look at the testcase in PR39233?

Thanks,
Richard.



More information about the Gcc-patches mailing list