https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68529
--- Comment #6 from majun <majun4950646 at 163 dot com> ---
(In reply to bin.cheng from comment #5)
> The dump before ldist is as below:
>
> foo1 ()
> {
> unsigned int nchar;
> char c[10000];
>
> <bb 2>:
> c = {};
>
> <bb 3>:
> # nchar_14 = PHI <nchar_5(4), 9998(2)>
> c[nchar_14] = 65;
> nchar_5 = nchar_14 + 4294967295;
> if (nchar_14 != 0)
> goto <bb 4>;
> else
> goto <bb 5>;
>
> <bb 4>:
> goto <bb 3>;
>
> <bb 5>:
> bar (&c);
> c ={v} {CLOBBER};
> return 0;
>
> }
>
> Apparently, nchar_14 iterates from 9998 to 0 in the loop and it doesn't
> overflow, while nchar_5 does overflow for the last iterations. It's true
> &c[n_char_14] is an affine since the index doesn't overflow.
> When I introduced the change computing non-overlfow control-iv in loop niter
> analysis, I only did it for the simplest case, ie, loop exit condition with
> LT comp code. This case falls in another case, ie, NE as the comp code. I
> think this can be fixed in the same framework. Actually it's easy to enable
> non-overflow control-iv computation in this case, then we can use the
> recorded control-iv to prove that (sizetype)nchar_14 doesn't overflow and
> &c[nchar_14] is an affine.
>
> I will dig deeper and test a patch for this.
>
> Thanks,
> bin
Does https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02317.html describe your
framework ?
it seems for now loop_exits_before_overflow should only handle th LT and GT
case ?
I'll see how does this framework do.
Thanks,
Jun
