Re: [patch] (-fstrict-overflow) optimize counted loops on signed iv

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

Hello,

> >>This allows to optimize loops like :
> >>for (i = start; i <= start+1; i++) ...
> >
> >
> >>-      niter->may_be_zero =   boolean_type_node,
> >>-					iv1->base, iv0->base);
> >
> >
> >I sort of do not understand why you need this change.  fold is (or
> >should be) able to derive that start < start + 1, if the computation
> >is performed in TYPE_OVERFLOW_UNDEFINED type.
> >
> 
> fold is currently not doing it in this context. and then I thought that 
> it wasn't needed if it is already trivially known at that point than the 
> count is constant.
> 
> if it's cleaner to fix 'fold', I can try to look at it (I'm quite eager 
> to improve dhrystone) unless someone here already knowns exactly where 
> to go in fold_const for that. What do you prefer ?

this simplification seems simple enough, and it might appear in other
contexts as well, so I think that in this case, fold is the right place
where to fix that.  I will check what is the problem (I am somewhat
surprised we do not fold this already).

> >Nevertheless, this looks just wrong.  relative_count_iv does not compare
> >the relative values of the bases of the induction variables, hence
> >this would also make you eliminate the the may_be_zero assumptions in
> >cases like
> >
> >for (i = a + 17; i < a + 5; i++)
> >
> >which is obviously wrong.
> >
> 
> This case is tested just before calling 'number_of_iterations_lt' in 
> 'number_of_iterations_cond ':
> /* If the loop exits immediately, there is nothing to do.  */

If fold succeeds to fold the expression base0 < base1, your patch does
not help.  If it does not, then this check in number_of_iterations_cond
won't succeed, either.

Zdenek