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

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

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
The interesting thing is that the difference starts with pattern recog (for the
epilogue loop) where the main loop recognizes a bool pattern but the epilogue
one
does not.  That's because 'long long unsigned int' doesn't have a vector type
with V4QImode.

But then vect_recog_cast_forwprop_pattern makes this cast irrelevant but we
do not re-visit the bool pattern as we only (re-)process the pattern def
sequence stmts but not the stmt itself:

  /* If this statement has already been replaced with pattern statements,
     leave the original statement alone, since the first match wins.
     Instead try to match against the definition statements that feed
     the main pattern statement.  */
  if (STMT_VINFO_IN_PATTERN_P (stmt_info))
    {
      gimple_stmt_iterator gsi;
      for (gsi = gsi_start (STMT_VINFO_PATTERN_DEF_SEQ (stmt_info));
           !gsi_end_p (gsi); gsi_next (&gsi))
        vect_pattern_recog_1 (vinfo, recog_func,
                              vinfo->lookup_stmt (gsi_stmt (gsi)));
      return;
    }

and we're also not expecting to do this:

void
vect_mark_pattern_stmts (vec_info *vinfo,
                         stmt_vec_info orig_stmt_info, gimple *pattern_stmt,
                         tree pattern_vectype)
{
...
      /* We shouldn't be replacing the main pattern statement.  */
      gcc_assert (STMT_VINFO_RELATED_STMT (orig_stmt_info)->stmt
                  != orig_pattern_stmt);

but bool pattern recog is required for correctness, we are not going to
fail vectorization later.

Richard - you added most of the re-processing of patterns (and also the
forwprop pattern that triggers the failure situation).  Can you share
insights and maybe fix this?

It's also really a latent issue.  One could use __int128_t to trigger it
for V8QI vectorization, but that's likely it - the trigger is the FAIL
of the bool pattern recog (which should probably a fatal vectorization
FAIL in case the stmt is ending up relevant).

What "works" (for the testcase) is to not terminate vect_recog_bool_pattern
when we have no vector type for the LHS but allow NULL to be propagated
through the pattern machinery (nothing will in the end use that type
for this testcase).  As said, since bool patterns are required for
correctness we cannot really early-out here but need to communicate
failure upthread.  I'm going to test a patch with this route.

Reply via email to