https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98550
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #49948|0 |1
is obsolete| |
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 49951
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49951&action=edit
patch
So while technically correct this interferes with group splitting:
FAIL: gcc.dg/vect/bb-slp-19.c -flto -ffat-lto-objects scan-tree-dump-times
slp2 "optimized: basic block" 1
FAIL: gcc.dg/vect/bb-slp-19.c scan-tree-dump-times slp2 "optimized: basic
block" 1
FAIL: gcc.dg/vect/bb-slp-pr58135.c -flto -ffat-lto-objects
scan-tree-dump-times slp2 "optimized: basic block" 1
FAIL: gcc.dg/vect/bb-slp-pr58135.c scan-tree-dump-times slp2 "optimized: basic
block" 1
bb-slp-19.c has a grouped store of size 9 where we immediately fail due to
the check which is "fatal" as in
tree nunits_vectype;
if (!vect_get_vector_types_for_stmt (vinfo, stmt_info, &vectype,
&nunits_vectype, group_size)
|| (nunits_vectype
&& !vect_record_max_nunits (vinfo, stmt_info, group_size,
nunits_vectype, max_nunits)))
{
if (is_a <bb_vec_info> (vinfo) && i != 0)
continue;
/* Fatal mismatch. */
matches[0] = false;
return false;
which means we do not re-try with splitting the store group up.
Now, starting analysis with a group size of 9 is never going to
succeed. Also note that get_vectype_for_scalar_type mimics the old
test:
/* If the natural choice of vector type doesn't satisfy GROUP_SIZE,
try again with an explicit number of elements. */
if (vectype
&& group_size
&& maybe_ge (TYPE_VECTOR_SUBPARTS (vectype), group_size))
{
but the fix must be to how we go discover splitting opportunities I guess.
One option is to only "soft-fail" for max_nunits issues, but then analysis
would still stop at the store (maybe that's even good - who knows, but
how far the match is good is only going to be determined later).
