[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Eh, we can't even _dump_ those VECTOR_CST:

#0  internal_error (gmsgid=0x29cb490 "tree check: %s, have %s in %s, at %s:%d")
    at ../../src/trunk/gcc/diagnostic.c:1804
#1  0x00000000017d00ea in tree_check_failed (
    node=<poly_int_cst 0x7ffff6f25300>, 
    file=0x2858ad0 "../../src/trunk/gcc/tree.h", line=5984, 
    function=0x285fe70 <wi::to_wide(tree_node const*)::__FUNCTION__> "to_wide")
    at ../../src/trunk/gcc/tree.c:9812
#2  0x0000000000ad994d in tree_check (__t=<poly_int_cst 0x7ffff6f25300>, 
    __f=0x2858ad0 "../../src/trunk/gcc/tree.h", __l=5984, 
    __g=0x285fe70 <wi::to_wide(tree_node const*)::__FUNCTION__> "to_wide", 
    __c=INTEGER_CST) at ../../src/trunk/gcc/tree.h:3594
#3  0x0000000000b56c27 in wi::to_wide (t=<poly_int_cst 0x7ffff6f25300>)
    at ../../src/trunk/gcc/tree.h:5984
#4  0x00000000017d75b2 in vector_cst_int_elt (t=<vector_cst 0x7ffff6f2e050>, 
    i=3) at ../../src/trunk/gcc/tree.c:11104
#5  0x00000000017d7798 in vector_cst_elt (t=<vector_cst 0x7ffff6f2e050>, i=3)
    at ../../src/trunk/gcc/tree.c:11131
#6  0x00000000014e0e2c in dump_generic_node (pp=0x3754e00, 
    node=<vector_cst 0x7ffff6f2e050>, spc=0, flags=2112, is_stmt=false)
    at ../../src/trunk/gcc/tree-pretty-print.c:2112

11101     /* Otherwise work out the value from the last two encoded elements. 
*/
11102     tree v1 = VECTOR_CST_ENCODED_ELT (t, final_i - npatterns);
11103     tree v2 = VECTOR_CST_ENCODED_ELT (t, final_i);
11104     wide_int diff = wi::to_wide (v2) - wi::to_wide (v1);
(gdb) p v1
$5 = <poly_int_cst 0x7ffff6f25300>
(gdb) p v2
$6 = <poly_int_cst 0x7ffff6f25320>

now if such VECTOR_CST is well-formed (well ...?), then with using
poly_wide_int in vector_cst_int_elt we at least get to RTL expansion where
we ICE like

#0  fancy_abort (file=0x28dd290 "../../src/trunk/gcc/rtl.h", line=2296, 
    function=0x28e84a0 <wi::int_traits<std::pair<rtx_def*, machine_mode>
>::decompose(long*, unsigned int, std::pair<rtx_def*, machine_mode>
const&)::__FUNCTION__> "decompose") at ../../src/trunk/gcc/diagnostic.c:1884
#1  0x0000000000e17546 in wi::int_traits<std::pair<rtx_def*, machine_mode>
>::decompose (precision=32, x=...) at ../../src/trunk/gcc/rtl.h:2296
#2  0x0000000000e45617 in wide_int_ref_storage<false,
false>::wide_int_ref_storage<std::pair<rtx_def*, machine_mode> >
(this=0x7fffffffc5a0, x=..., 
    precision=32) at ../../src/trunk/gcc/wide-int.h:1034
#3  0x0000000000e427e7 in generic_wide_int<wide_int_ref_storage<false, false>
>::generic_wide_int<std::pair<rtx_def*, machine_mode> > (this=0x7fffffffc5a0, 
    x=..., precision=32) at ../../src/trunk/gcc/wide-int.h:790
#4  0x0000000000e405be in wi::sub<std::pair<rtx_def*, machine_mode>,
std::pair<rtx_def*, machine_mode> > (x=..., y=...) at
../../src/trunk/gcc/wide-int.h:2512
#5  0x000000000132743f in rtx_vector_builder::step (this=0x7fffffffc7a0, 
    elt1=0x7ffff6f2f0c0, elt2=0x7ffff6f2f0e0)
    at ../../src/trunk/gcc/rtx-vector-builder.h:122
#6  0x000000000132795e in vector_builder<rtx_def*, machine_mode,
rtx_vector_builder>::elt (this=0x7fffffffc7a0, i=3)
    at ../../src/trunk/gcc/vector-builder.h:254
#7  0x0000000001327051 in rtx_vector_builder::build (this=0x7fffffffc7a0)
    at ../../src/trunk/gcc/rtx-vector-builder.c:73
#8  0x0000000000eb109a in const_vector_from_tree (
    exp=<vector_cst 0x7ffff6f2e078>) at ../../src/trunk/gcc/expr.c:12763

Richard - are POLY_INT_CST element VECTOR_CST well-formed?  It seems
they are introduced during vectorization but there they are simple
like { POLY_INT_CST [4, 4], ... } but then FRE4 produces

Value numbering stmt = _48 = vect_cst__46 + { 0, 1, 2, ... };
Match-and-simplified vect_cst__46 + { 0, 1, 2, ... } to { POLY_INT_CST [16,
16], POLY_INT_CST [17, 16], POLY_INT_CST [18, 16], ... }

and things start to go downhill.