[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"

["az.zaafrani at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052

--- Comment #12 from zaafrani <az.zaafrani at gmail dot com> ---
Thank you for the feedback.

We excluded start value that is constant because it is already
working. To our knowledge, only when the start value is unknown and
the loop index type is of unsigned type that we fail to recognize
non-overflow for situations when it is possible to deduce so. For most
other cases, current analysis done in scev_probably_wraps_p seems to
be working fine. We also added the assumption of step equal 1 so that
we can make correct decision about non-overflow. So, basically weâd
rather catch few simple cases and make them work  then try to
generalize the scope and not being to prove much.


On Wed, May 6, 2015 at 1:56 AM, rguenth at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
>
> --- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
> That's an interesting idea - your argument is that if niter analysis was able
> to compute an expression for the number of iterations and the cast we are
> looking at
> is a widening of a BIV then it is ok to assume the BIV does not wrap.
>
> Unfortunately this breaks down (eventually not in practice due to your
> exclusion of constant initial BIV value) for cases like
>
>
>   for (unsigned i = 3; i != 2; i+=7)
>     ;
>
> where niter analysis can still compute the number of iterations (I've made
> the numbers up, so maybe that loop will never terminate...).
>
> Still the idea is interesting as we might be able to record whether BIVs
> overflow or not.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.