[Bug tree-optimization/56157] New: ICE with -ftree-vectorize in in compute_live_loop_exits (4.8 trunk)

[Bug tree-optimization/56157] New: ICE with -ftree-vectorize in in compute_live_loop_exits (4.8 trunk)

[jana at saout dot de]

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

             Bug #: 56157
           Summary: ICE with -ftree-vectorize in in
                    compute_live_loop_exits (4.8 trunk)
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jana@saout.de


When compiling mesa-9.0.1 using the latest gcc trunk from SVN, I noticed the
following ICE (seems to have been introduced at least a week ago, worked with
some earlier 4.8.0 versions I haven't pinpointed).

LANG=C gcc -O2 -ftree-vectorize -c lala.c
lala.c: In function ‘fn’:
lala.c:14:6: internal compiler error: in compute_live_loop_exits, at
tree-ssa-loop-manip.c:219
 void fn(unsigned char *dst_row, unsigned dst_stride,
      ^

lala.c:14:6: internal compiler error: Aborted
gcc: internal compiler error: Aborted (program cc1)

(on x86_64, reproducable with and without -m32)

With the following reduced testcase:

------------------------------
#include <string.h>
#include <stdint.h>

union Pixel {
   uint64_t value;
   struct {
      unsigned short r;
      unsigned short g;
      unsigned short b;
      unsigned short a;
   } chan;
};

void fn(unsigned char *dst_row, unsigned dst_stride,
        const unsigned char *src_row, unsigned src_stride,
        unsigned width, unsigned height)
{
   unsigned x, y;
   for(y = 0; y < height; y += 1) {
      const unsigned char *src = src_row;
      unsigned char *dst = dst_row;
      for(x = 0; x < width; x += 1) {
         union Pixel pixel;
         pixel.chan.r = (unsigned short)(((unsigned)src[0]) * 0xffff / 0xff);
         pixel.chan.g = (unsigned short)(((unsigned)src[1]) * 0xffff / 0xff);
         pixel.chan.b = (unsigned short)(((unsigned)src[2]) * 0xffff / 0xff);
         pixel.chan.a = (unsigned short)(((unsigned)src[3]) * 0xffff / 0xff);
         memcpy(dst, &pixel, sizeof pixel);
         src += 4;
         dst += 8;
      }
      dst_row += dst_stride;
      src_row += src_stride/sizeof(*src_row);
   }
}
------------------------------

gcc version:

Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-beta20130130/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-beta20130130/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.0_beta20130130/work/gcc-4.8-20130130/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-beta20130130
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-beta20130130/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-beta20130130
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-beta20130130/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-beta20130130/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-beta20130130/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-cloog --disable-isl-version-check
--disable-cloog-version-check --with-cloog-include=/usr/include/cloog
--enable-cloog-backend=isl --enable-lto --enable-nls --without-included-gettext
--with-system-zlib --enable-obsolete --disable-werror --enable-secureplt
--enable-multilib --with-multilib-list=m32,m64
--with-build-config=bootstrap-lto --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-beta20130130/python
--enable-checking=release --enable-java-awt=gtk --enable-libstdcxx-time
--enable-languages=c,c++,java,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.8.0_beta20130130'
Thread model: posix
gcc version 4.8.0-beta20130130 20130130 (experimental) (Gentoo
4.8.0_beta20130130) 

(it says Gentoo because I used the build environment, but it's essentially a
vanilla gcc build which I am regularly throwing the SVN version at and building
the system with)

[Bug tree-optimization/56157] [4.8 Regression] ICE with -ftree-vectorize in in compute_live_loop_exits

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-01-31
                 CC|                            |jakub at gcc dot gnu.org
   Target Milestone|---                         |4.8.0
            Summary|ICE with -ftree-vectorize   |[4.8 Regression] ICE with
                   |in in                       |-ftree-vectorize in in
                   |compute_live_loop_exits     |compute_live_loop_exits
                   |(4.8 trunk)                 |
     Ever Confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-31 08:46:27 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190284
Looking into it.

[Bug tree-optimization/56157] [4.8 Regression] ICE with -ftree-vectorize in in compute_live_loop_exits

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-31 09:05:24 UTC ---
Seems that SVN revision just turned a silent miscompilation into an ICE.
In r190283 the vectorizer generated:
  vect_cst_.56_200 = { 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535
};
  vect_cst_.58_205 = {D.1740_224(D), D.1746_225(D), D.1752_226(D),
D.1758_227(D)};
  vect_cst_.59_206 = { 2155905153, 2155905153, 2155905153, 2155905153 };
before the loop, while D.17{40,46,52,58} were all initialized inside of the
loop.

[Bug tree-optimization/56157] [4.8 Regression] ICE with -ftree-vectorize in in compute_live_loop_exits

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-31 09:14:57 UTC ---
The silent miscompilation started with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188656
(before that it wasn't vectorized), but perhaps it was latent before.

[Bug tree-optimization/56157] [4.8 Regression] ICE with -ftree-vectorize in in compute_live_loop_exits

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-31 11:09:40 UTC ---
The problematic stmt is placed by:
#0  vect_init_vector_1 (stmt=0x7ffff1abb6e0, new_stmt=0x7ffff1ad6a00, gsi=0x0)
at ../../gcc/tree-vect-stmts.c:1240
#1  0x0000000000c36087 in vect_init_vector (stmt=0x7ffff1abb6e0,
val=0x7ffff1aa3ea0, type=0x7ffff1ace2a0, gsi=0x0)
    at ../../gcc/tree-vect-stmts.c:1310
#2  0x0000000000c649f9 in vect_get_constant_vectors (op=0x7ffff1ac10d8,
slp_node=0x18eb4d0, vec_oprnds=0x18eb470, op_num=0, number_of_vectors=4, 
    reduc_index=-1) at ../../gcc/tree-vect-slp.c:2539
#3  0x0000000000c64f1c in vect_get_slp_defs (ops=..., slp_node=0x18eb4d0,
vec_oprnds=0x7fffffffd750, reduc_index=-1)
    at ../../gcc/tree-vect-slp.c:2696
#4  0x0000000000c3686b in vect_get_vec_defs (op0=0x7ffff1ac10d8,
op1=0x7ffff1ac3c20, stmt=0x7ffff1abb6e0, vec_oprnds0=0x7fffffffd7e0, 
    vec_oprnds1=0x7fffffffd7d0, slp_node=0x18eb4d0, reduc_index=-1) at
../../gcc/tree-vect-stmts.c:1593
#5  0x0000000000c3cc73 in vectorizable_operation (stmt=0x7ffff1abb6e0,
gsi=0x7fffffffda20, vec_stmt=0x7fffffffd980, slp_node=0x18eb4d0)
    at ../../gcc/tree-vect-stmts.c:3728
#6  0x0000000000c43330 in vect_transform_stmt (stmt=0x7ffff1abb6e0,
gsi=0x7fffffffda20, grouped_store=0x7fffffffda3a, slp_node=0x18eb4d0, 
    slp_node_instance=0x18eb8d0) at ../../gcc/tree-vect-stmts.c:5793
#7  0x0000000000c65de3 in vect_schedule_slp_instance (node=0x18eb4d0,
instance=0x18eb8d0, vectorization_factor=4)
    at ../../gcc/tree-vect-slp.c:3095
#8  0x0000000000c659e2 in vect_schedule_slp_instance (node=0x18eb360,
instance=0x18eb8d0, vectorization_factor=4)
    at ../../gcc/tree-vect-slp.c:3020
#9  0x0000000000c659e2 in vect_schedule_slp_instance (node=0x18eb290,
instance=0x18eb8d0, vectorization_factor=4)
    at ../../gcc/tree-vect-slp.c:3020
#10 0x0000000000c659e2 in vect_schedule_slp_instance (node=0x18eafd0,
instance=0x18eb8d0, vectorization_factor=4)
    at ../../gcc/tree-vect-slp.c:3020
#11 0x0000000000c66054 in vect_schedule_slp (loop_vinfo=0x18e1710,
bb_vinfo=0x0) at ../../gcc/tree-vect-slp.c:3165
#12 0x0000000000c5570c in vect_transform_loop (loop_vinfo=0x18e1710) at
../../gcc/tree-vect-loop.c:5693

One thing that might be problematic is that stmt in this case is a pattern
stmt, not original one, but my reading of vect_init_vector_1 shows that
probably it shouldn't make a difference, it only cares about gimple_bb of the
stmt (which should be the same between pattern and original stmt) and some
details from stmt_vinfo (STMT_VINFO_LOOP_VINFO and STMT_VINFO_BB_VINFO should
be the same too, in this case the first one is non-NULL (and not a nested
loop), the latter is NULL).

So, IMHO, either the bug is in vect_get_constant_vectors where it doesn't
supply
non-NULL last argument to vect_init_vector call, or in vect_get_slp_defs.
Given
"For constant and loop invariant defs of SLP_NODE this function returns"...
comment probably not vect_get_constant_vectors fault, the arguments in this
case aren't constant nor loop invariant.
But given:
"Otherwise, the def-stmts must be already vectorized and the vectorized stmts
must be stored in the corresponding child of SLP_NODE, and we call
vect_get_slp_vect_defs () to retrieve them."
the bug might be somewhere earlier too.

Richard, can you please have a look?  Thanks.

[Bug tree-optimization/56157] [4.8 Regression] ICE with -ftree-vectorize in in compute_live_loop_exits

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-31 11:45:42 UTC ---
Mine.

[Bug tree-optimization/56157] [4.8 Regression] ICE with -ftree-vectorize in in compute_live_loop_exits

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-31 11:54:09 UTC ---
Reduced testcase:

struct Pixel {
    unsigned short r;
    unsigned short g;
    unsigned short b;
    unsigned short a;
};

void fn(unsigned char *dst, const unsigned char *src, unsigned width)
{
  unsigned x;
  for(x = 0; x < width; x += 1)
    {
      struct Pixel pixel;
      pixel.r = (unsigned short)(((unsigned)src[0]) * 0xffff / 0xff);
      pixel.g = (unsigned short)(((unsigned)src[1]) * 0xffff / 0xff);
      pixel.b = (unsigned short)(((unsigned)src[2]) * 0xffff / 0xff);
      pixel.a = (unsigned short)(((unsigned)src[3]) * 0xffff / 0xff);
      __builtin_memcpy(dst, &pixel, sizeof pixel);
      src += 4;
      dst += 8;
    }
}

[Bug tree-optimization/56157] [4.8 Regression] ICE with -ftree-vectorize in in compute_live_loop_exits

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-31 11:59:06 UTC ---
Even more reduced, avoids any loop versioning in the vectorizer:

struct Pixel {
    unsigned short r;
    unsigned short g;
    unsigned short b;
    unsigned short a;
};

void fn(unsigned char * __restrict dst, const unsigned char * __restrict src)
{
  unsigned x;
  for(x = 0; x < 1024; x += 1)
    {
      struct Pixel pixel;
      pixel.r = (unsigned short)(((unsigned)src[0]) * 0xffff / 0xff);
      pixel.g = (unsigned short)(((unsigned)src[1]) * 0xffff / 0xff);
      pixel.b = (unsigned short)(((unsigned)src[2]) * 0xffff / 0xff);
      pixel.a = (unsigned short)(((unsigned)src[3]) * 0xffff / 0xff);
      __builtin_memcpy(dst, &pixel, sizeof pixel);
      src += 4;
      dst += 8;
    }
}

[Bug tree-optimization/56157] [4.8 Regression] ICE with -ftree-vectorize in in compute_live_loop_exits

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-31 14:45:46 UTC ---
The check

          /* In the end of a pattern sequence we have a use of the original
stmt,
             so we need to compare OPRND with the original def.  */
          if (is_pattern_stmt_p (vinfo_for_stmt (first_def))
              && !STMT_VINFO_IN_PATTERN_P (vinfo_for_stmt (first_stmt))
              && !is_pattern_stmt_p (vinfo_for_stmt (first_stmt)))

seems bogus.  We have two adjacent (but independent) pattern stmts, so
first_stmt and first_def are both patterns.  I think what the code tries to
do is check whether first_def is the "main" pattern stmt (thus if
the scalar stmt _10 = _9 * 65535 would have the pattern
_tem = ...; patt_10 = _tem ...; thus be of size 2 it likes to know if
first_def is patt_10 and not _tem).

So, something like

          if (is_pattern_stmt_p (vinfo_for_stmt (first_def))
              && STMT_VINFO_RELATED_STMT 
                  (vinfo_for_stmt 
                    (STMT_VINFO_RELATED_STMT 
                      (vinfo_for_stmt (first_def)))) == first_def)

that is, if the main pattern stmt (RELATED_STMT) of the scalar stmt
for the pattern group (RELATED_STMT of first_def if that is a pattern)
is first_def.

Well.  If I remember the mess of pattern vs. RELATED_STMT correctly ...

That doesn't fix the ICE, but the generated code looks better.  Apart
from that we still have a weird

  vect_cst_.14_38 = {_64, _60, _56, _52, _64, _60, _56, _52};

now without any defs for the operands ... it's from

_64 = (unsigned short) _8;
patt_63 = _64 w* 65535;

the pattern generated for

_9 = (unsigned int) _8;
_10 = _9 * 65535

but STMT_VINFO_RELATED_STMT are

_64 = (unsigned short) _8; -> _9 = (unsigned int) _8;
_9 = (unsigned int) _8; -> _64 = (unsigned short) _8;

t.c:11: note: patt_63 = _64 w* 65535;
t.c:11: note: pattern recognized: patt_63 = _64 w* 65535;
t.c:11: note: additional pattern stmt: _64 = (unsigned short) _8;

that's unexpected to me.  It seems there is no way to detect this
"end of a pattern sequence"?  Maybe what really is wanted is

          /* In the end of a pattern sequence we have a use of the original
stmt,
             so we need to compare OPRND with the original def.  */
          first_def_info = vinfo_for_stmt (first_def);
          if (STMT_VINFO_IN_PATTERN_P (first_def_info))
            first_def = STMT_VINFO_RELATED_STMT (first_def_info);

?!

What it seems to try to do is see if we are processing operands of a
"leaf" pattern stmt - thus one with operands not in a pattern.
Then it tries to compensate for that with using the scalar stmt
for the pattern stmt of the definition of the operand.

But it seems to me that the def always has to match the operand
anyway, be it pattern or not, and thus the check is completely
superflous?  Seems to work at least.  Giving it more testing.

Hmm, it breaks BB SLP at least.  Here the ops array we hand to
vect_get_slp_defs does not match up with SLP_TREE_CHILDREN.
Like for _12 = x_11(D) * a0_4; we get one child, but that matches up
with x_11(D) - which is of course wrong.  So it seems that the
operand comparison code is to verify we are indeed looking at the
correct SLP_TREE_CHILDREN entry ... skipping appearantly "unused" ones.
*sigh*

[Bug tree-optimization/56157] [4.8 Regression] ICE with -ftree-vectorize in in compute_live_loop_exits

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-31 14:54:05 UTC ---
The issue is latent on the 4.7 branch.

[Bug tree-optimization/56157] [4.8 Regression] ICE with -ftree-vectorize in in compute_live_loop_exits

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-31 16:52:36 UTC ---
Author: rguenth
Date: Thu Jan 31 16:52:28 2013
New Revision: 195616

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195616
Log:
2013-01-31  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/56157
    * tree-vect-slp.c (vect_get_slp_defs): More thoroughly try to
    match up operand with SLP child.

    * gcc.dg/torture/pr56157.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr56157.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/56157] [4.8 Regression] ICE with -ftree-vectorize in in compute_live_loop_exits

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-31 16:53:44 UTC ---
Fixed on trunk.