https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 3 Mar 2021, bina2374 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092 > > --- Comment #11 from Mel Chen <bina2374 at gmail dot com> --- > (In reply to Mel Chen from comment #10) > > (In reply to Richard Biener from comment #9) > > > (In reply to Mel Chen from comment #8) > > > > Sorry for using the bad example to describe the problem I am facing. > > > > Let me > > > > clarify my question with a more precise example. > > > > > > > > void array_mul(int N, int *C, short *A, short *B) { > > > > int i, j; > > > > for (i = 0; i < N; i++) { > > > > C[i] = 0; // Will be transformed to __builtin_memset > > > > for (j = 0; j < N; j++) { > > > > C[i] += (int)A[i * N + j] * (int)B[j]; > > > > } > > > > } > > > > } > > > > > > > > If I compile the case with -O2 -fno-tree-loop-distribute-patterns, the > > > > store > > > > operation 'C[i] = 0' can be eliminated by dead store elimination > > > > (dse3). But > > > > without -fno-tree-loop-distribute-patterns, it will be transformed to > > > > memset > > > > by loop distribution (ldist) because ldist executes before dse3. > > > > Finally the > > > > memset will not be eliminated. > > > > > > > > Another point is if there are other operations in the same level loop > > > > as the > > > > store operation, is it really beneficial to do loop distribution and > > > > then > > > > convert to builtin function? > > > > > > Sure, it shows a cost modeling issue given that usually loop distribution > > > merges partitions which touch the same memory stream (but IIRC maybe only > > > for loads). But more to the point we're missing to eliminate the dead > > > store > > > which should be appearant at least after PRE - LIM2 applied store motion > > > but only PRE elides the resulting load of C[i]. Usually DCE and DSE come > > > in > > > pairs but after PRE we have DCE, CDDCE w/o accompaning DSE only with the > > > next DSE only happening after loop distribution. > > > > > > Which means we should eventually do > > > > > > diff --git a/gcc/passes.def b/gcc/passes.def > > > index e9ed3c7bc57..be3a9becde0 100644 > > > --- a/gcc/passes.def > > > +++ b/gcc/passes.def > > > @@ -254,6 +254,7 @@ along with GCC; see the file COPYING3. If not see > > > NEXT_PASS (pass_sancov); > > > NEXT_PASS (pass_asan); > > > NEXT_PASS (pass_tsan); > > > + NEXT_PASS (pass_dse); > > > NEXT_PASS (pass_dce); > > > /* Pass group that runs when 1) enabled, 2) there are loops > > > in the function. Make sure to run pass_fix_loops before > > > > Yes, doing DSE before ldist is a simple and effective way. > > This patch has been verified to be work on coremark. Not only improved > > performance, but also code size. > > The test case gcc.dg/tree-ssa/ldist-33.c is failure after I added DSE. > > /* { dg-do compile { target size32plus } } */ > /* { dg-options "-O2 -ftree-loop-distribution -ftree-loop-distribute-patterns > -fdump-tree-ldist-details" } */ > > #define N (1024) > double a[N][N], b[N][N], c[N][N]; > > void > foo (void) > { > unsigned i, j, k; > > for (i = 0; i < N; ++i) > for (j = 0; j < N; ++j) > { > c[i][j] = 0.0; > for (k = 0; k < N; ++k) > c[i][j] += a[i][k] * b[k][j]; > } > } > > /* { dg-final { scan-tree-dump "Loop nest . distributed: split to 1 loops and > 1 > library" "ldist" } } */ > > It is similar to the example I showed earlier. DSE eliminated 'c[i][j] = 0.0' > so no loop will be split. My question is how to handle this test case? Add > -fno-tree-dse into dg-options, modify this test case, delete this test case, > or > others. I'd say disable store-motion with a comment (-fno-tree-loop-im, we might also finally add a separate switch to control the store-motion part of GIMPLE invariant motion). I think the testcase should show we can recognize the memset in a non-innermost loop (IIRC the above mimics what bwaves does).
