On Mon, Sep 13, 2021 at 1:49 PM Christophe Lyon
<christophe.lyon....@gmail.com> wrote:

> This last test now fails on aarch64:
> FAIL:  gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps 
> threaded: 8"
>
> Can you check?

These rather large tests checking for some random number of jump
threads are very annoying.  In all my work in the past 2 years,
they've never found anything that the smaller threading tests (for
instance ssa-thread-14.c) couldn't find.

The thing is that the new backward threader is not a threader per se,
but a framework for solving paths.  It can find virtually any path in
the IL, depending on how good the solver or the path discovery bits
are.  So any change to a great number of components can alter the
number of threads.  For example, changes to at *least* the following
components could alter the number of threads:

* the path solver
* the path discovery bits in tree-ssa-threadbackward
* the profitability code in tree-ssa-threadbackward
* the post-registration bits in the low-level path registry
* range-ops
* ranger
* any pass alterting global SSA_NAME_RANGE_INFO since the path solver
can pull that info (evrp, VRP, sprintf, PRE, strlen, loop-manip, etc).

It is unreasonable to have to go through every assumed jump thread
candidate in these tests for every minor change.  Heck, are we even
sure there are supposed to be 18 exact jump threads in the first
backward jump thread pass for this test?

I suggest we remove these tests.  They add a maintenance burder, for
very little return.  And if we _really_ must test something in this
area, perhaps a unit test in the appropriate component would be more
useful.

For this particular test the IL is sufficiently different on aarch64,
such that the number of threads is different.  I'm just going to
disable this.  We already have to disable the dom3 and vrp2 jump
threading  tests on this same test on aarch64.  This is more of the
same.  Committed to trunk.

I'd be happy to hear if anyone has other solutions.
Aldy
commit a7f59856ea8ea02d6f09d2e9e793ce2800ebbe4b
Author: Aldy Hernandez <al...@redhat.com>
Date:   Mon Sep 13 14:25:15 2021 +0200

    Adjust ssa-dom-thread-7.c on aarch64.
    
    gcc/testsuite/ChangeLog:
    
            * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust for aarch64.

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
index ba07942f9dd..e3d4b311c03 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
@@ -2,7 +2,7 @@
 /* { dg-options "-O2 -fdump-tree-thread1-stats -fdump-tree-thread2-stats -fdump-tree-dom2-stats -fdump-tree-thread3-stats -fdump-tree-dom3-stats -fdump-tree-vrp2-stats -fno-guess-branch-probability" } */
 
 /* { dg-final { scan-tree-dump "Jumps threaded: 18"  "thread1" } } */
-/* { dg-final { scan-tree-dump "Jumps threaded: 8" "thread3" } } */
+/* { dg-final { scan-tree-dump "Jumps threaded: 8" "thread3" { target { ! aarch64*-*-* } } } } */
 /* { dg-final { scan-tree-dump-not "Jumps threaded"  "dom2" } } */
 
 /* aarch64 has the highest CASE_VALUES_THRESHOLD in GCC.  It's high enough

Reply via email to