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