public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r13-3133] Fix wrong code generated by unroll-and-jam pass
Date: Thu,  6 Oct 2022 13:17:03 +0000 (GMT)	[thread overview]
Message-ID: <20221006131703.5DA173938C3F@sourceware.org> (raw)

https://gcc.gnu.org/g:3ec926d36fbf7cb3ff45759471139f3a71d1c4de

commit r13-3133-g3ec926d36fbf7cb3ff45759471139f3a71d1c4de
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Thu Oct 6 15:13:50 2022 +0200

    Fix wrong code generated by unroll-and-jam pass
    
    There is a loophole in the unroll-and-jam pass that can quickly result in
    wrong code generation.  The code reads:
    
        if (!compute_data_dependences_for_loop (outer, true, &loop_nest,
                                    &datarefs, &dependences))
            {
              if (dump_file && (dump_flags & TDF_DETAILS))
                fprintf (dump_file, "Cannot analyze data dependencies\n");
              free_data_refs (datarefs);
              free_dependence_relations (dependences);
              continue;
            }
    
    but compute_data_dependences_for_loop may return true even if the analysis
    is reported as failing by compute_affine_dependence for a dependence pair:
    
    (compute_affine_dependence
      ref_a: data[_14], stmt_a: data[_14] = i_59;
      ref_b: data[_14], stmt_b: data[_14] = i_59;
    Data ref a:
    Data ref b:
    affine dependence test not usable: access function not affine or constant.
    ) -> dependence analysis failed
    
    Note that this is a self-dependence pair and the code for them reads:
    
              /* Nothing interesting for the self dependencies. */
              if (dra == drb)
                continue;
    
    This means that the pass may reorder "complex" accesses to the same memory
    location in successive iterations, which is OK for reads but not for writes.
    
    gcc/
            * gimple-loop-jam.cc (tree_loop_unroll_and_jam): Bail out for a self
            dependency that is a write-after-write if the access function is not
            affine or constant.
    
    gcc/testsuite/
            * gcc.c-torture/execute/20221006-1.c: New test.

Diff:
---
 gcc/gimple-loop-jam.cc                           | 18 +++++++++++++--
 gcc/testsuite/gcc.c-torture/execute/20221006-1.c | 29 ++++++++++++++++++++++++
 2 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/gcc/gimple-loop-jam.cc b/gcc/gimple-loop-jam.cc
index a8a57d3d384..4f7a6e5bbae 100644
--- a/gcc/gimple-loop-jam.cc
+++ b/gcc/gimple-loop-jam.cc
@@ -545,11 +545,25 @@ tree_loop_unroll_and_jam (void)
 	  /* If the refs are independend there's nothing to do.  */
 	  if (DDR_ARE_DEPENDENT (ddr) == chrec_known)
 	    continue;
+
 	  dra = DDR_A (ddr);
 	  drb = DDR_B (ddr);
-	  /* Nothing interesting for the self dependencies.  */
+
+	  /* Nothing interesting for the self dependencies, except for WAW if
+	     the access function is not affine or constant because we may end
+	     up reordering writes to the same location.  */
 	  if (dra == drb)
-	    continue;
+	    {
+	      if (DR_IS_WRITE (dra)
+		  && !DR_ACCESS_FNS (dra).is_empty ()
+		  && DDR_ARE_DEPENDENT (ddr) == chrec_dont_know)
+		{
+		  unroll_factor = 0;
+		  break;
+		}
+	      else
+		continue;
+	    }
 
 	  /* Now check the distance vector, for determining a sensible
 	     outer unroll factor, and for validity of merging the inner
diff --git a/gcc/testsuite/gcc.c-torture/execute/20221006-1.c b/gcc/testsuite/gcc.c-torture/execute/20221006-1.c
new file mode 100644
index 00000000000..80deb3a148f
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/20221006-1.c
@@ -0,0 +1,29 @@
+#include <stdlib.h>
+
+int
+main (int argc, char** argv)
+{
+  const int len = argc == 2 ? atoi(argv[1]) : 4;
+
+  int count;
+  int data[64];
+  int M1[len][len];
+  int M2[len][len];
+
+  for (int i = 0; i < len; i++)
+    for (int j = 0 ; j < len ; j++)
+      M1[i][j] = M2[i][j] = i*len + j;
+
+  M2[1][0] = M2[0][1];
+
+  /* This writes successively 0 and 1 into data[M2[0][1]].  */
+  for (int i = 0; i < len - 1; i++)
+    for (int j = 0 ; j < len ; j++)
+      if (M1[i+1][j] > M1[i][j]) 
+        data[M2[i][j]] = i;
+
+  if (data [M2[0][1]] != 1)
+    abort ();
+
+  return 0;
+}

                 reply	other threads:[~2022-10-06 13:17 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221006131703.5DA173938C3F@sourceware.org \
    --to=ebotcazou@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).