https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97173
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
t.i:12:29: note: node 0x53dcd70 (max_nunits=2, refcnt=2)
t.i:12:29: note: stmt 0 _4 = _1 + _3;
t.i:12:29: note: stmt 1 _4 = _1 + _3;
t.i:12:29: note: stmt 2 _5 = _4 + _3;
t.i:12:29: note: stmt 3 _5 = _4 + _3;
t.i:12:29: note: children 0x5578e20 0x53de920
t.i:12:29: note: node (external) 0x5578e20 (max_nunits=1, refcnt=1)
t.i:12:29: note: { _1, _1, _4, _4 }
t.i:12:29: note: node (external) 0x53de920 (max_nunits=1, refcnt=1)
t.i:12:29: note: { _3, _3, _3, _3 }
hmm, another case of a "weird" SLP grouping (the 0x53dcd70 node computes
some operand lanes itself, _4 = _1 + 3). We're also getting the costing
wrong here and think _1 + _3 can be eliminated. Now the code tries to exactly
catch this case:
/* ??? This can happen when the live lane ends up being
used in a vector construction code-generated by an
external SLP node (and code-generation for that already
happened). See gcc.dg/vect/bb-slp-47.c.
Doing this is what would happen if that vector CTOR
were not code-generated yet so it is not too bad.
??? In fact we'd likely want to avoid this situation
in the first place. */
if (gimple_code (use_stmt) != GIMPLE_PHI
&& !vect_stmt_dominates_stmt_p (gsi_stmt (*gsi), use_stmt))
{
gcc_assert (is_gimple_assign (use_stmt)
&& gimple_assign_rhs_code (use_stmt) ==
CONSTRUCTOR)
but the assert fails to consider the case where the CTOR elements need to be
converted (here pointer to unsigned long) and thus the use_stmts are
not the CTOR but the conversion.
Of course as the comment says we likely want to avoid this situation and
instead
elide 0x53dcd70 to be external itself.
For now I'm going to adjust the assert.
