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: linkBe 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).