On 9/28/2021 12:17 AM, Aldy Hernandez wrote:
On Tue, Sep 28, 2021 at 3:46 AM Jeff Law <jeffreya...@gmail.com> wrote:
On 9/27/2021 9:00 AM, Aldy Hernandez wrote:
Last year I mentioned that -fthread-jumps was being ignored by the
majority of our jump threading passes, and Jeff said he'd be in favor
of fixing this.
This patch remedies the situation, but it does change existing behavior.
Currently -fthread-jumps is only enabled for -O2, -O3, and -Os. This
means that even if we restricted all jump threading passes with
-fthread-jumps, DOM jump threading would still seep through since it
runs at -O1.
I propose this patch, but it does mean that DOM jump threading would
have to be explicitly enabled with -O1 -fthread-jumps. An
alternative would be to also offer a specific -fno-dom-threading, but
that seems icky.
OK pending tests?
gcc/ChangeLog:
* tree-ssa-threadbackward.c (pass_thread_jumps::gate): Check
flag_thread_jumps.
(pass_early_thread_jumps::gate): Same.
* tree-ssa-threadedge.c (jump_threader::thread_outgoing_edges):
Return if !flag_thread_jumps.
* tree-ssa-threadupdate.c
(jt_path_registry::register_jump_thread): Assert that
flag_thread_jumps is true.
OK. Clearly this is going to be even better once we disentangle
threading from DOM.
Annoyingly, I had to tweak a few more tests, particularly some
-Wuninitialized -O1 ones which seem to depend on DOM jump threading to
give proper diagnostics. It seems that every change to jump threading
needs tweaks to the Wuninitialized code :-(.
Well, a lot of jump threading is there to help eliminate false positives
from Wuninitialized by eliminating paths through the CFG that we can
prove never execute at runtime. SO that's not a huge surprise.
jeff
