]> git.ipfire.org Git - thirdparty/gcc.git/commit
Avoid invalid loop transformations in jump threading registry.
authorAldy Hernandez <aldyh@redhat.com>
Thu, 23 Sep 2021 08:59:24 +0000 (10:59 +0200)
committerAldy Hernandez <aldyh@redhat.com>
Fri, 24 Sep 2021 06:25:42 +0000 (08:25 +0200)
commit4a960d548b7d7d942f316c5295f6d849b74214f5
tree2bb1ed9fcf27bd928129ef4a49b7ad379407307d
parent29c92857039d0a105281be61c10c9e851aaeea4a
Avoid invalid loop transformations in jump threading registry.

My upcoming improvements to the forward jump threader make it thread
more aggressively.  In investigating some "regressions", I noticed
that it has always allowed threading through empty latches and across
loop boundaries.  As we have discussed recently, this should be avoided
until after loop optimizations have run their course.

Note that this wasn't much of a problem before because DOM/VRP
couldn't find these opportunities, but with a smarter solver, we trip
over them more easily.

Because the forward threader doesn't have an independent localized cost
model like the new threader (profitable_path_p), it is difficult to
catch these things at discovery.  However, we can catch them at
registration time, with the added benefit that all the threaders
(forward and backward) can share the handcuffs.

This patch is an adaptation of what we do in the backward threader, but
it is not meant to catch everything we do there, as some of the
restrictions there are due to limitations of the different block
copiers (for example, the generic copier does not re-use existing
threading paths).

We could ideally remove the now redundant bits in profitable_path_p, but
I would prefer not to for two reasons.  First, the backward threader uses
profitable_path_p as it discovers paths to avoid discovering paths in
unprofitable directions.  Second, I would like to merge all the forward
cost restrictions into the profitability class in the backward threader,
not the other way around.  Alas, that reshuffling will have to wait for
the next release.

As usual, there are quite a few tests that needed adjustments.  It seems
we were quite happily threading improper scenarios.  With most of them,
as can be seen in pr77445-2.c, we're merely shifting the threading to
after loop optimizations.

Tested on x86-64 Linux.

gcc/ChangeLog:

* tree-ssa-threadupdate.c (jt_path_registry::cancel_invalid_paths):
New.
(jt_path_registry::register_jump_thread): Call
cancel_invalid_paths.
* tree-ssa-threadupdate.h (class jt_path_registry): Add
cancel_invalid_paths.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/20030714-2.c: Adjust.
* gcc.dg/tree-ssa/pr66752-3.c: Adjust.
* gcc.dg/tree-ssa/pr77445-2.c: Adjust.
* gcc.dg/tree-ssa/ssa-dom-thread-18.c: Adjust.
* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust.
* gcc.dg/vect/bb-slp-16.c: Adjust.
gcc/testsuite/gcc.dg/tree-ssa/20030714-2.c
gcc/testsuite/gcc.dg/tree-ssa/pr66752-3.c
gcc/testsuite/gcc.dg/tree-ssa/pr77445-2.c
gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-18.c
gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
gcc/testsuite/gcc.dg/vect/bb-slp-16.c
gcc/tree-ssa-threadupdate.c
gcc/tree-ssa-threadupdate.h