https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC| |rguenth at gcc dot gnu.org,
| |rsandifo at gcc dot gnu.org
Last reconfirmed| |2022-01-13
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think
/* If the target does not support partial vectors we can shorten the
number of modes to analyze for the epilogue as we know we can't pick a
mode that has at least as many NUNITS as the main loop's vectorization
factor, since that would imply the epilogue's vectorization factor
would be at least as high as the main loop's and we would be
vectorizing for more scalar iterations than there would be left. */
if (!supports_partial_vectors
&& maybe_ge (GET_MODE_NUNITS (vector_modes[mode_i]), first_vinfo_vf))
{
is completely bogus - for -1b.c we autodetect V8SImode and first_vinfo_vf is 8
so we skip V8SImode which is OK. But then vector_modes[1] is V32QImode,
it doesn't make sense to compare NUNITS of a vector mode with the VF of a loop
(or NUNITS of two vector modes with different element mode).
Previously we started from mode_i of the first loop or what it would consider
as next mode which I suppose provided this "skipping" in case the mode
array is sorted after VF (and not preference).
That said, for this case we do nothing until we hit V4QImode which obviously
cannot be used to vectorize a double.
