aboutsummaryrefslogtreecommitdiff
path: root/gcc/tree-ssa-threadupdate.c
diff options
context:
space:
mode:
authorAldy Hernandez <aldyh@redhat.com>2021-10-20 07:29:25 +0200
committerAldy Hernandez <aldyh@redhat.com>2021-10-26 08:20:10 +0200
commitf6d012338bf87f427b7420f2f309963c29fe33ba (patch)
tree200193b9fcdb72bfbd2a9933007a7bbeb186f1c5 /gcc/tree-ssa-threadupdate.c
parentf3dbd3f36d55178d0a9e4431043cbc950524969a (diff)
downloadgcc-f6d012338bf87f427b7420f2f309963c29fe33ba.zip
gcc-f6d012338bf87f427b7420f2f309963c29fe33ba.tar.gz
gcc-f6d012338bf87f427b7420f2f309963c29fe33ba.tar.bz2
Try to resolve paths in threader without looking further back.
Sometimes we can solve a candidate path without having to recurse further back. This can mostly happen in fully resolving mode, because we can ask the ranger what the range on entry to the path is, but there's no reason this can't always apply. This one-liner removes the fully-resolving restriction. I'm tickled pink to see how many things we now get quite early in the compilation. I actually had to disable jump threading entirely for a few tests because the early threader was catching things disturbingly early. Also, as Richi predicted, I saw a lot of pre-VRP cleanups happening. I was going to commit this as obvious, but I think the test changes merit discussion. We've been playing games with gcc.dg/tree-ssa/ssa-thread-11.c for quite some time. Every time a threading pass gets smarter, we push the check further down the pipeline. We've officially run out of dumb threading passes to disable ;-). In the last year we've gone up from a handful of threads, to 34 threads with the current combination of options. I doubt this is testing anything useful anymore, so I've removed it. Similarly for gcc.dg/tree-ssa/ssa-dom-thread-4.c. We used to thread 3 jump threads, but they were disallowed because of loop rotation. Then we started catching more jump threads in VRP2 threading so we tested there. With this patch though, we triple the number of threads found from 11 to 31. I believe this test has outlived its usefulness, and I've removed it. Note that even though we have these outrageous possibilities for this test, the block copier ultimately chops them down (23 survive though). Tested on x86-64 Linux. gcc/ChangeLog: * tree-ssa-threadbackward.c (back_threader::find_paths_to_names): Always try to resolve path without looking back. * tree-ssa-threadupdate.c (dump_jump_thread): Indidicate whether edge is a back edge. gcc/testsuite/ChangeLog: * gcc.dg/graphite/scop-dsyr2k-2.c: Adjust for jump threading changes. * gcc.dg/graphite/scop-dsyr2k.c: Same. * gcc.dg/graphite/scop-dsyrk-2.c: Same. * gcc.dg/graphite/scop-dsyrk.c: Same. * gcc.dg/tree-ssa/pr20701.c: Same. * gcc.dg/tree-ssa/pr20702.c: Same. * gcc.dg/tree-ssa/pr21086.c: Same. * gcc.dg/tree-ssa/pr25382.c: Same. * gcc.dg/tree-ssa/pr58480.c: Same. * gcc.dg/tree-ssa/ssa-vrp-thread-1.c: Same. * gcc.dg/tree-ssa/vrp08.c: Same. * gcc.dg/tree-ssa/vrp55.c: Same. * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Same. * gcc.dg/tree-ssa/ssa-dom-thread-4.c: Removed. * gcc.dg/tree-ssa/ssa-thread-11.c: Removed. * gcc.dg/uninit-pr89230-1.c: xfail.
Diffstat (limited to 'gcc/tree-ssa-threadupdate.c')
-rw-r--r--gcc/tree-ssa-threadupdate.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index 8e6f043..8aac733 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -253,6 +253,9 @@ dump_jump_thread_path (FILE *dump_file,
default:
gcc_unreachable ();
}
+
+ if ((path[i]->e->flags & EDGE_DFS_BACK) != 0)
+ fprintf (dump_file, " (back)");
}
fprintf (dump_file, "; \n");
}