Re: [PATCH] Control all jump threading passes with -fjump-threads.

[Richard Biener <richard.guenther@gmail.com>]

On Tue, Sep 28, 2021 at 8:29 AM Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 9/28/2021 12:17 AM, Aldy Hernandez wrote:
> > On Tue, Sep 28, 2021 at 3:46 AM Jeff Law <jeffreyalaw@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.

I would have suggested to enable -fthread-jumps at -O1 instead
and eventually just add && flag_expensive_optimizations to the
use in cfgcleanup.c to restrict that to -O2+

Richard.

> jeff