[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE

[stammark at gcc dot gnu.org]

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

--- Comment #5 from Stam Markianos-Wright <stammark at gcc dot gnu.org> ---
(In reply to rsandifo@gcc.gnu.org from comment #4)
> (In reply to Stam Markianos-Wright from comment #3)
> > Just started looking at this. I've narrowed it as the bug appearing with
> > commit 9b75f56d4b7951c60a656396dddd4a65787b95bc.
> > 
> > I have yet to fire this up in gdb to see what's happening, but one test I
> > did do was to try commenting out the assert that is causing the ICE and it
> > then ran to completion. 
> > 
> > So one _total speculation_ would be that with these latest changes that
> > enable groups of different sizes, this condition in the assert is now too
> > strict:
> > 
> > 
> > multiple_p (TYPE_VECTOR_SUBPARTS (nunits_vectype),
> > 	    TYPE_VECTOR_SUBPARTS (*stmt_vectype_out)))
> What are nunits_vectype and *stmt_vectype_out at the point
> that the assert fails?

Hmm so looking at this on commit 9b75f56d4b7951c60a656396dddd4a65787b95bc,
we have:



nunits_vectype is a: vector(SUBPARTS {coeffs = {4, 0}}) float

*stmt_vectype_out is a: vector(SUBPARTS {coeffs = {8, 0}}) long int

In this case we are checking multiple_p (4, 8) == false
(and also group_size == 9 here which is expected)



Before the commit we'd get here with:



nunits_vectype is a: vector(SUBPARTS {coeffs = {4, 0}}) float

*stmt_vectype_out is a: vector(SUBPARTS {coeffs = {2, 0}}) long int

And here we were checking multiple_p (4, 2) == true



I'm tempted to try and add a reverse:

        || multiple_p (*stmt_vectype_out, nunits_vectype)

And then regtest, but I probably need to do more reading around to figure out
what we really should be expecting each case!