https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #7 from bin cheng <amker at gcc dot gnu.org> ---
(In reply to Jiu Fu Guo from comment #5)
> (In reply to bin cheng from comment #4)
> > (In reply to Jiu Fu Guo from comment #3)
> > > Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow
> > > tricky:
> > >
> > > /* Only support simple cases for the moment. */
> > > if (TREE_CODE (iv0->base) != INTEGER_CST
> > > || TREE_CODE (iv1->base) != INTEGER_CST)
> > > return false;
> > >
> > > This code requires both sides are constant.
> > Actually it requires an IV with constant base.
>
> I also feel that the intention of this function may only require one side
> constant for IV0 CODE IV1.
> As tests, for below loop, adjust_cond_for_loop_until_wrap return false:
>
> foo (int *__restrict__ a, int *__restrict__ b, unsigned i)
> {
> while (++i > 100)
> *a++ = *b++ + 1;
> }
>
> For below code, adjust_cond_for_loop_until_wrap returns true:
> i = UINT_MAX - 200;
> while (++i > 100)
> *a++ = *b++ + 1;
Oh sorry for being misleading. When I mentioned it requires something(...), I
was describing the current behavior, not that the conditions are necessary.
Feel free to improve such cases. Looking into niter analysis, these
cases(trade-offs) are not rare.
Thanks
