[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

2017-11-22 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82713

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

2017-11-19 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82713

--- Comment #7 from Jan Hubicka  ---
Author: hubicka
Date: Sun Nov 19 18:52:54 2017
New Revision: 254933

URL: https://gcc.gnu.org/viewcvs?rev=254933=gcc=rev
Log:

PR target/82713
* i386.c (ix86_builtin_vectorization_cost): Be ready for insane
types.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr82713.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

2017-11-19 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82713

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #6 from Jan Hubicka  ---
Mine.

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

2017-11-19 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82713

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Jan Hubicka  ---
Created attachment 42655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42655=edit
Patch I am testing.

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

2017-10-26 Thread andrey.y.guskov at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82713

--- Comment #4 from Andrey Guskov  ---
Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=slm --with-cpu=slm

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

2017-10-26 Thread andrey.y.guskov at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82713

Andrey Guskov  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #3 from Andrey Guskov  ---
r254012 also triggers gcc.target/i386/pr61403.c:

PASS: gcc.target/i386/pr61403.c (test for excess errors)
FAIL: gcc.target/i386/pr61403.c scan-assembler blend

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

2017-10-25 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82713

--- Comment #2 from Richard Biener  ---
non-SLP manages to get by using scalar_to_vec given it only handles the case of
all constants/externals being the same value.  As said the costing
infrastructure
inside the vectorizer itself is somewhat limiting.

I suggest you work around in the backend for now, I'll take this "bug" as an
excuse to work on the cost model during stage3.

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

2017-10-25 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82713

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-25
 CC||rguenth at gcc dot gnu.org
Version|unknown |8.0
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

2017-10-25 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82713

--- Comment #1 from Richard Biener  ---
My bet is boolean vectors with QI/HImode.  But eventually the vectorizer uses
vector_load on sth not being a vector load as well.  Yeah...

  /* Without looking at the actual initializer a vector of
 constants can be implemented as load from the constant pool.
 ???  We need to pass down stmt_info for a vector type
 even if it points to the wrong stmt.  */
  if (dt == vect_constant_def)
record_stmt_cost (prologue_cost_vec, 1, vector_load,
  stmt_info, 0, vect_prologue);

so the stmt vector type is

 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x766955e8 precision:1 min  max >
HI
size  constant 128>
unit-size  constant 16>
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76695690 nunits:16>

as I said.  The stmt we're looking at is

_2 = _1 <= 10;

so for costing the proper vector type would be not the boolean vector type
but the vector type of the operand.

Cost of constant handling in SLP is a hack (somewhat).  Given we're
using the new & shiny cost interface here there's no way to stuff down
the "proper" vector type.  Not passing stmt_info down would make the
constant case work but the external case quite pointless.

As said, you can't expect the "correct" vector type to be passed down
consistently :/