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

[Christian BRUEL <christian dot bruel at st dot com>]

for my curiosity, I just had a quick look at fold-const and it looks 
like 'fold_relational_const' only handle the case were ops are INTEGER_CST :

  /* Compute a result for LT or EQ if args permit;
     Otherwise return T.  */
  if (TREE_CODE (op0) == INTEGER_CST && TREE_CODE (op1) == INTEGER_CST)
    {
      if (code == EQ_EXPR)
	result = tree_int_cst_equal (op0, op1);
      else if (TYPE_UNSIGNED (TREE_TYPE (op0)))
	result = INT_CST_LT_UNSIGNED (op0, op1);
      else
	result = INT_CST_LT (op0, op1);
    }
  else
    return NULL_TREE;

so the PLUS_EXPR/MINUS_EXPR cases are missing.

Do you want a bugzilla defect to track it ?

Regards

-c
Zdenek Dvorak wrote:
> 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