[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[rguenth at gcc dot gnu.org]

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.