diff mbox series

Control all jump threading passes with -fjump-threads.

Message ID 20210927150003.796951-1-aldyh@redhat.com
State New
Headers
Series Control all jump threading passes with -fjump-threads. |

Commit Message

Aldy Hernandez Sept. 27, 2021, 3 p.m. UTC 
  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.
---
 gcc/testsuite/gcc.dg/tree-ssa/pr18133-2.c | 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/pr18134.c   | 2 +-
 gcc/tree-ssa-threadbackward.c             | 4 ++--
 gcc/tree-ssa-threadedge.c                 | 3 +++
 gcc/tree-ssa-threadupdate.c               | 2 ++
 5 files changed, 9 insertions(+), 4 deletions(-)

Comments

Jeff Law Sept. 28, 2021, 1:46 a.m. UTC | #1 
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.
jeff
Aldy Hernandez Sept. 28, 2021, 6:17 a.m. UTC | #2 
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
Jeff Law Sept. 28, 2021, 6:28 a.m. UTC | #3 
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.

jeff
Richard Biener Sept. 28, 2021, 7:41 a.m. UTC | #4 
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
Aldy Hernandez Sept. 28, 2021, 9:42 a.m. UTC | #5 
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 <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+

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?
Aldy
Richard Biener Sept. 28, 2021, 10:54 a.m. UTC | #6 
On Tue, Sep 28, 2021 at 11:42 AM Aldy Hernandez <aldyh@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 <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+
>
> 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
diff mbox series

Patch

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr18133-2.c b/gcc/testsuite/gcc.dg/tree-ssa/pr18133-2.c
index 8717640e327..1b409852189 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr18133-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr18133-2.c
@@ -1,5 +1,5 @@ 
 /* { dg-do compile } */
-/* { dg-options "-O1 -fdump-tree-optimized-blocks" } */
+/* { dg-options "-O1 -fthread-jumps -fdump-tree-optimized-blocks" } */
 
 int c, d;
 
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr18134.c b/gcc/testsuite/gcc.dg/tree-ssa/pr18134.c
index cd40ab2c162..d7f5d241eb9 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr18134.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr18134.c
@@ -1,5 +1,5 @@ 
 /* { dg-do compile } */
-/* { dg-options "-O1 -fdump-tree-optimized" } */
+/* { dg-options "-O1 -fthread-jumps -fdump-tree-optimized" } */
 
 int  foo (int a)
 {
diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index 95542079faf..8940728cbf2 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -943,7 +943,7 @@  public:
 bool
 pass_thread_jumps::gate (function *fun ATTRIBUTE_UNUSED)
 {
-  return flag_expensive_optimizations;
+  return flag_thread_jumps && flag_expensive_optimizations;
 }
 
 // Try to thread blocks in FUN.  Return TRUE if any jump thread paths were
@@ -1013,7 +1013,7 @@  public:
 bool
 pass_early_thread_jumps::gate (function *fun ATTRIBUTE_UNUSED)
 {
-  return true;
+  return flag_thread_jumps;
 }
 
 unsigned int
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index ae77e5eb396..e6f0ff0b54b 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -1195,6 +1195,9 @@  jump_threader::thread_outgoing_edges (basic_block bb)
   int flags = (EDGE_IGNORE | EDGE_COMPLEX | EDGE_ABNORMAL);
   gimple *last;
 
+  if (!flag_thread_jumps)
+    return;
+
   /* If we have an outgoing edge to a block with multiple incoming and
      outgoing edges, then we may be able to thread the edge, i.e., we
      may be able to statically determine which of the outgoing edges
diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index 2b9b8f81274..cf96c903668 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -2822,6 +2822,8 @@  jt_path_registry::cancel_invalid_paths (vec<jump_thread_edge *> &path)
 bool
 jt_path_registry::register_jump_thread (vec<jump_thread_edge *> *path)
 {
+  gcc_checking_assert (flag_thread_jumps);
+
   if (!dbg_cnt (registered_jump_thread))
     {
       path->release ();