https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77621
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |x86_64-*-*, i?86-*-*
Status|NEW |ASSIGNED
CC| |uros at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine. The issue is that we have a non-vectorizable load as part of an
interleaving group (that stmt is later not used in the SLP).
But the odd part of this testcase is that we have
t.c:7:1: note: not vectorized: no vectype for stmt: _51 = *x_18(D);
scalar_type: double
t.c:7:1: note: got vectype for stmt: _32 = *_33;
vector(4) int
t.c:7:1: note: got vectype for stmt: _25 = *_28;
vector(2) double
this seems to be a backend issue with targetm.vectorize.preferred_simd_mode
(DFmode) which seems to return SImode (!?) but once we fixed vector size
by looking for a SImode vector mode (V4SImode) mode_for_vector happily
returns V2DFmode for us to use.
So it seems V2DFmode is available but discouraged via the above hook when
tuning for atom.
Indeed:
static machine_mode
ix86_preferred_simd_mode (machine_mode mode)
{
...
case DFmode:
if (!TARGET_VECTORIZE_DOUBLE)
return word_mode;
but targetm.vector_mode_supported_p happily returns true for V2DFmode.
This means the above is _not_ a good way to achieve what it tries to
(make the vectorizer not use V2DFmode). A more proper way would be to
handle this in ix86_add_stmt_cost, increasing the cost for double type
vectorization.
Nevertheless the vectorizer shouldn't ICE on this inconsistency, I'll see
what it takes to "fix" it on the vectorizer side.
