[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

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

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
The power7 failure with

FAIL: gcc.dg/vect/vect-complex-5.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2

Shows that alignment checking as done in get_group_load_store_type does not
match what we later code-generate.  The first group, storing into

      c[i].f1 = a1[i] + b1[i];

is said to be aligned while the second

      c[i].f2 = a2[i] + b2[i];

is said to be unaligned and thus unsupported.  In reality both are
VMAT_STRIDED_SLP which can end up with a variety of alignment requirements.
In this case we emit a series of SImode stores to SImode aligned memory
in both cases.

Thus,

static bool
get_group_load_store_type (vec_info *vinfo, stmt_vec_info stmt_info,
...
  if (*memory_access_type == VMAT_GATHER_SCATTER
      || *memory_access_type == VMAT_ELEMENTWISE)
    *alignment_support_scheme = dr_unaligned_supported;
  else
    *alignment_support_scheme
      = vect_supportable_dr_alignment (vinfo, first_dr_info, false);

is incomplete and misses special-casing of VMAT_STRIDED_SLP.  For
VMAT_ELEMENTWISE we seem to simply assume that element (scalar)
misaligned accesses are OK (ISTR we reject non-element aligned vectorization),
but with VMAT_STRIDED_SLP we eventually use SImode to access two HImode
components which are not necessarily aligned according to SImode.

There's the related bug where the alignment we compute for a vector DR
is biased when the stride is negative and which also results in bogus
alignment to be used for checks.

ISTR I wrote somewhere that vectorizable_load/store analysis & costing
should possibly simply run through a common code path for analysis
and code generation (fending off actual stmt generation for analysis)
to avoid this kind of disconnect between code gen assumptions and
analysis parts.  Thus the classical if (!vec_stmt) return early; approach
isn't good for maintainance.

That said, gcc.dg/vect/vect-complex-5.c is a missed optimization on
!hw-misaligned targets, thus I'm going to XFAIL it for ! vect_hw_misalign.