[Bug tree-optimization/57558] New: Issue with number of iterations calculation

[Bug tree-optimization/57558] New: Issue with number of iterations calculation

[ysrumyan at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558

            Bug ID: 57558
           Summary: Issue with number of iterations calculation
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ysrumyan at gmail dot com

For the following simple test-case extracted from 254.gap (spec2000):

typedef unsigned long ul;
void foo (ul* __restrict x, ul* __restrict y, ul n)
{
  ul i;
  for (i=1; i<=n; i++, x++, y++)
    *x ^= *y;
}

gcc cannot determine number of iterations and failed to vectorize loop:

t1.c:5: note: === get_loop_niters ===Analyzing # of iterations of loop 1
  exit condition [2, + , 1] <= n_8(D)
  bounds on difference of bases: -1 ... 4294967293
  result:
    under assumptions n_8(D) != 4294967295
    # of iterations n_8(D) + 4294967295, bounded by 4294967294

t1.c:5: note: not vectorized: number of iterations cannot be computed.

Note that if we change for-stmt to
  for (i=0; i<n; i++, x++, y++)

it will be vectorized.

[Bug tree-optimization/57558] Issue with number of iterations calculation

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |53947

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
That's because the first variant can loop infinitely for n == ULONG_MAX
and that "infinite" cannot be represented using new induction variable
as the vectorizer wants to.  Well, not easily at least.

[Bug tree-optimization/57558] Issue with number of iterations calculation

[a.sinyavin at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558

Anatoly Sinyavin <a.sinyavin at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |a.sinyavin at samsung dot com

--- Comment #2 from Anatoly Sinyavin <a.sinyavin at samsung dot com> ---
There is "-Wunsafe-loop-optimizations" option. This option switches on warnings
about such potential "infinite" loops.

Question: if we have this option should we fix this problem ?

[Bug tree-optimization/57558] Issue with number of iterations calculation

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-05-06
                 CC|                            |alalaw01 at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Seeing this too.

Is another approach to fall back to an alternative (scalar?) path (perhaps just
the epilogue?) if we can tell at the beginning of the loop that the iteration
count will be infinite?

[Bug tree-optimization/57558] Loop not vectorized if iteration count could be infinite

[alalaw01 at gcc dot gnu.org]

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

--- Comment #4 from alalaw01 at gcc dot gnu.org ---
Here's another example, extracted from another benchmark - it vectorizes if
INDEX is defined to 'long' but not if INDEX is 'short':

#include <stdlib.h>

unsigned char *t_run_test(unsigned char *in, int N)
{
  unsigned char *out = malloc (N);

  for (unsigned INDEX i = 1; i < (N - 1); i++)
    out[i] = ((3 * in[i]) - in[i - 1] - in[i + 1]);

  return out;
}

However, the -Wunsafe-loop-optimizations doesn't give us anything useful here:

(successful case, warning printed)
$ aarch64-none-elf-gcc -O3 bmark2.c -DINDEX=long -S -Wunsafe-loop-optimizations
-fdump-tree-vect-details=stdout | grep vectorized
bmark2.c:7:3: note: === vect_mark_stmts_to_be_vectorized ===
bmark2.c:7:3: note: loop vectorized
bmark2.c:3:16: note: vectorized 1 loops in function.
bmark2.c: In function 't_run_test':
bmark2.c:3:16: warning: cannot optimize loop, the loop counter may overflow
[-Wunsafe-loop-optimizations]
 unsigned char *t_run_test(unsigned char *in, int N)

(unsuccessful case, no warning)
$ aarch64-none-elf-gcc -O3 bmark2.c -DINDEX=short -S
-Wunsafe-loop-optimizations -fdump-tree-vect-details=stdout | grep vectorized
bmark2.c:7:3: note: not vectorized: number of iterations cannot be computed.
bmark2.c:3:16: note: vectorized 0 loops in function.