On Tue, Sep 28, 2021 at 11:42 AM Aldy Hernandez <al...@redhat.com> wrote: > > > > On 9/28/21 9:41 AM, Richard Biener wrote: > > 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 <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. > > > > 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+ > > Hmmm, that's a much better idea. I was afraid of messing existing > behavior, but I suppose adding even more false positives for -O1 > -Wuninitialized is worse. > > BTW, I plugged one more tweak to the registry in > remove_jump_threads_including. No need to go add things to the removed > edges hash table, if we're not going to thread. > > OK pending tests?
OK. Richard. > Aldy
