public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/94261] New: [10 Regression] ICE in vect_get_vec_def_for_operand_1 for 3-element condition reduction
@ 2020-03-22 11:46 rsandifo at gcc dot gnu.org
  2020-03-22 12:20 ` [Bug tree-optimization/94261] " rguenther at suse dot de
                   ` (12 more replies)
  0 siblings, 13 replies; 14+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2020-03-22 11:46 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 94261
           Summary: [10 Regression] ICE in vect_get_vec_def_for_operand_1
                    for 3-element condition reduction
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rsandifo at gcc dot gnu.org
                CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
            Target: aarch64*-*-*

The following test ICEs when compiled with
-O3 -ffinite-math-only -march=armv8.2-a+sve
on aarch64:

void
f (float *x, float *y, float z)
{
  float res0 = 0, res1 = 1, res2 = 2;
  for (int i = 0; i < 100; ++i)
    {
      res0 = 100 <= y[i * 3] ? res0 : z;
      res1 = 101 <= y[i * 3 + 1] ? res1 : z;
      res2 = y[i * 3 + 2] < 102 ? z : res2;
    }
  x[0] = res0;
  x[1] = res1;
  x[2] = res2;
}

The ICE is:

b.c:2:1: internal compiler error: in vect_get_vec_def_for_operand_1, at
tree-vect-stmts.c:1555
    2 | f (float *x, float *y, float z)
      | ^
0x10a86c3 vect_get_vec_def_for_operand_1(_stmt_vec_info*, vect_def_type)
        gcc/tree-vect-stmts.c:1555
0x10af8e1 vect_get_vec_def_for_operand(tree_node*, _stmt_vec_info*, tree_node*)
        gcc/tree-vect-stmts.c:1617
0x10b258f vectorizable_condition
        gcc/tree-vect-stmts.c:10213
0x10d01ea vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
        gcc/tree-vect-stmts.c:11012
0x10d4226 vect_transform_loop_stmt
        gcc/tree-vect-loop.c:8307
0x10ec31a vect_transform_loop(_loop_vec_info*, gimple*)
        gcc/tree-vect-loop.c:8707
0x110f797 try_vectorize_loop_1
        gcc/tree-vectorizer.c:990
0x1110319 vectorize_loops()
        gcc/tree-vectorizer.c:1126

The problem comes from trying both SVE and Advanced SIMD and
eventually picking SVE.  The SVE version can't treat the loop
as a single 3-element SLP reduction because we don't yet
support loading { 100, 101, 102 } repeating for variable-length
vectors.  We therefore fail the SLP build before doing anything
about the awkward comparison arrangement.  With this version,
each ?: is a separate reduction and each one has its own,
correct, STMT_VINFO_REDUC_IDX.

But then we try the Advanced SIMD version.  This doesn't have
a problem with loading the constants, so we get as far as
dealing with mismatched comparisons:

          /* Swap.  */
          if (*swap == 1)
            {
              swap_ssa_operands (stmt, &TREE_OPERAND (cond, 0),
                                 &TREE_OPERAND (cond, 1));
              TREE_SET_CODE (cond, swap_tree_comparison (code));
            }
          /* Invert.  */
          else
            {
              swap_ssa_operands (stmt, gimple_assign_rhs2_ptr (stmt),
                                 gimple_assign_rhs3_ptr (stmt));
              if (STMT_VINFO_REDUC_IDX (stmt_info) == 1)
                STMT_VINFO_REDUC_IDX (stmt_info) = 2;
              else if (STMT_VINFO_REDUC_IDX (stmt_info) == 2)
                STMT_VINFO_REDUC_IDX (stmt_info) = 1;
              bool honor_nans = HONOR_NANS (TREE_OPERAND (cond, 0));
              code = invert_tree_comparison (TREE_CODE (cond), honor_nans);
              gcc_assert (code != ERROR_MARK);
              TREE_SET_CODE (cond, code);
            }

But these changes to the gimple stmt persist even if the SLP build
fails later, or if the SLP build succeeds and we decide not to
vectorise that way.  That doesn't matter too much for the current
loop_vinfo, because the STMT_VINFO_REDUC_IDXs are still consistent
with the gimple stmt.  But it means that the STMT_VINFO_REDUC_IDXs
for the older SVE loop_vinfo are now no longer correct.

The ICE triggers when we go back to the SVE loop_vinfo as the
cheapest implementation and try to code-generate the reduction.

The testcase is reduced from 481.wrf compiled with LTO.

^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-03-23 15:55 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-22 11:46 [Bug tree-optimization/94261] New: [10 Regression] ICE in vect_get_vec_def_for_operand_1 for 3-element condition reduction rsandifo at gcc dot gnu.org
2020-03-22 12:20 ` [Bug tree-optimization/94261] " rguenther at suse dot de
2020-03-23  8:11 ` rguenth at gcc dot gnu.org
2020-03-23  9:57 ` rguenth at gcc dot gnu.org
2020-03-23 10:09 ` rguenth at gcc dot gnu.org
2020-03-23 10:10 ` rguenth at gcc dot gnu.org
2020-03-23 10:58 ` rsandifo at gcc dot gnu.org
2020-03-23 11:26 ` rguenth at gcc dot gnu.org
2020-03-23 11:35 ` rsandifo at gcc dot gnu.org
2020-03-23 11:40 ` rguenth at gcc dot gnu.org
2020-03-23 12:30 ` rguenth at gcc dot gnu.org
2020-03-23 13:44 ` rguenth at gcc dot gnu.org
2020-03-23 15:48 ` cvs-commit at gcc dot gnu.org
2020-03-23 15:55 ` rguenth at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).