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 :-(.

Attached is the patch I have pushed.

Aldy