[Bug tree-optimization/122762] [16 Regression] various SPECCPU 2017 benchmark ICEs with in prepare_vec_mask, at tree-vect-stmts.cc:1622

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

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

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we consider

 <vector_type 0x7fefefd7c3f0
    type <boolean_type 0x7fefefd7c498 public QI
        size <integer_cst 0x7fefefe1e030 constant 8>
        unit-size <integer_cst 0x7fefefe1e048 constant 1>
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fefefd7c498 precision:4 min <integer_cst 0x7fefefd43930 -8> max <integer_cst
0x7fefefd43a20 7>>
    VNx4BI
    size <poly_int_cst 0x7fefefcffec0
        type <integer_type 0x7fefefe1c0a8 bitsizetype public unsigned TI
            size <integer_cst 0x7fefefe02f78 constant 128>
            unit-size <integer_cst 0x7fefefe02f90 constant 16>
            align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fefefe1c0a8 precision:128 min <integer_cst 0x7fefefe02fa8 0> max
<integer_cst 0x7fefefe0c938 340282366920938463463374607431768211455>>
        constant
        elt0: <integer_cst 0x7fefefe1e0f0 constant 16> elt1: <integer_cst
0x7fefefe1e0f0 16>>

and 

 <vector_type 0x7fefefd7c348
    type <boolean_type 0x7fefefd7c498 public QI
        size <integer_cst 0x7fefefe1e030 constant 8>
        unit-size <integer_cst 0x7fefefe1e048 constant 1>
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fefefd7c498 precision:4 min <integer_cst 0x7fefefd43930 -8> max <integer_cst
0x7fefefd43a20 7>>
    VNx4BI
    size <poly_int_cst 0x7fefefcffec0
        type <integer_type 0x7fefefe1c0a8 bitsizetype public unsigned TI
            size <integer_cst 0x7fefefe02f78 constant 128>
            unit-size <integer_cst 0x7fefefe02f90 constant 16>
            align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fefefe1c0a8 precision:128 min <integer_cst 0x7fefefe02fa8 0> max
<integer_cst 0x7fefefe0c938 340282366920938463463374607431768211455>>
        constant
        elt0: <integer_cst 0x7fefefe1e0f0 constant 16> elt1: <integer_cst
0x7fefefe1e0f0 16>>

not compatible, because aarch64_compatible_vector_types_p they are not.

Not sure why this does not reproduce reliably.

So the issue is then likely that the

  bestn->simdclone->args[i].vector_type

is (sometimes?) a SVE builtin type and when we register that with the loop
mask things go downhill?

I do wonder why the middle-end should care about SVE builtin type vs. not.
We need to insert conversions there then?  And why the SVE builtin type
(identified by a type attribute) isn't a variant type of the non-builtin
one.