Re: Moving backwards/FSM threader into its own pass

[Jeff Law]

On 06/09/2016 05:18 AM, Martin Liška wrote:

Hello.

The patch caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466
THanks.  I've got a few issues to address related to that change -- I've 
just been swamped with some personal stuff the last week.


I'm seriously considering reverting the change at this point, addressing 
the issues, then re-installing as I expect to stay pretty busy in the 
immediate future.


jeff

Re: Moving backwards/FSM threader into its own pass

[Martin Liška]

Hello.

The patch caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466

Thanks,
Martin

Re: Moving backwards/FSM threader into its own pass

[Richard Biener]

On Tue, May 31, 2016 at 11:12 PM, Jeff Law  wrote:
> On 05/31/2016 11:38 AM, Richard Biener wrote:
>
>>> Essentially we want to limit the backwards substitution to single step
>>> within a single block for that case (which is trivially easy).  That
>>> would allow us to run a very cheap threader during early optimizations.
>>
>>
>> Just do double check - the pass does both forward and backward threading
>> and DOM/VRP now do neither themselves?
>
> Will do.  It's pretty easy.  I suspect there's a lot of low hanging fruit.
>
> The backward pass is strictly backward substitution & simplification and
> independent of DOM/VRP.  I believe we're ultimately going to want a param or
> something to determine how far back it goes in the IL.
>
> The old threader (still called from VRP/DOM) is primarily forward based
> using equivalence tables and ASSERT_EXPRs to simplify expressions as it
> walks statements in the block.
>
> I'm pretty sure everything done by the old threader can be more easily and
> efficiently modeled in the backwards threader.  One a couple infrastructure
> items are addressed, I want to start looking at cutting back on the amount
> of work done in the old threader with the goal of starting to eliminate
> calls into it completely.

Maybe to rephrase my question - DOM/VRP now do no threading anymore?
And the "backwards" threader is named "backwards" due to its implementation
and not because it only threads across backedges?

Richard.

> Jeff

Re: Moving backwards/FSM threader into its own pass

[Jeff Law]

On 05/31/2016 11:38 AM, Richard Biener wrote:


Essentially we want to limit the backwards substitution to single step
within a single block for that case (which is trivially easy).  That
would allow us to run a very cheap threader during early optimizations.


Just do double check - the pass does both forward and backward threading and 
DOM/VRP now do neither themselves?

Will do.  It's pretty easy.  I suspect there's a lot of low hanging fruit.

The backward pass is strictly backward substitution & simplification and 
independent of DOM/VRP.  I believe we're ultimately going to want a 
param or something to determine how far back it goes in the IL.


The old threader (still called from VRP/DOM) is primarily forward based 
using equivalence tables and ASSERT_EXPRs to simplify expressions as it 
walks statements in the block.


I'm pretty sure everything done by the old threader can be more easily 
and efficiently modeled in the backwards threader.  One a couple 
infrastructure items are addressed, I want to start looking at cutting 
back on the amount of work done in the old threader with the goal of 
starting to eliminate calls into it completely.


Jeff

Re: Moving backwards/FSM threader into its own pass

[Richard Biener]

On May 31, 2016 4:55:36 PM GMT+02:00, Jeff Law  wrote:
>On 05/30/2016 03:16 AM, Richard Biener wrote:
>>
>> Ok, but the placement (and number of) threading passes then no longer
>depends
>> on DOM/VRP passes - and as you placed the threading passes _before_
>those
>> passes the threading itself does not benefit from DOM/VRP but only
>from
>> previous optimization passes.
>Right.  Note that number of passes now is actually the same as we had 
>before, they're just occurring outside DOM/VRP.
>
>The backwards threader's only dependency on DOM/VRP was to propagate 
>constants into PHI nodes and to propagate away copies.  That dependency
>
>was removed.
>
>
>>
>> I see this as opportunity to remove some of them ;)  I now see in the
>main
>> optimization pipeline
>>
>>   NEXT_PASS (pass_fre);
>>   NEXT_PASS (pass_thread_jumps);
>>   NEXT_PASS (pass_vrp, true /* warn_array_bounds_p */);
>>
>> position makes sense - FRE removed redundancies and fully
>copy/constant
>> propagated the IL.
>>
>>   NEXT_PASS (pass_sra);
>>   /* The dom pass will also resolve all __builtin_constant_p
>calls
>>  that are still there to 0.  This has to be done after some
>>  propagations have already run, but before some more dead
>code
>>  is removed, and this place fits nicely.  Remember this when
>>  trying to move or duplicate pass_dominator somewhere
>earlier.  */
>>   NEXT_PASS (pass_thread_jumps);
>>   NEXT_PASS (pass_dominator, true /* may_peel_loop_headers_p */);
>>
>> this position OTOH doesn't make much sense as IL cleanup is missing
>> after SRA and previous opts.  After loop we now have
>We should look at this one closely.  The backwards threader doesn't 
>depend on IL cleanups.  It should do its job regardless of the state of
>
>the IL.
>
>
>>
>>   NEXT_PASS (pass_tracer);
>>   NEXT_PASS (pass_thread_jumps);
>>   NEXT_PASS (pass_dominator, false /* may_peel_loop_headers_p
>*/);
>>   NEXT_PASS (pass_strlen);
>>   NEXT_PASS (pass_thread_jumps);
>>   NEXT_PASS (pass_vrp, false /* warn_array_bounds_p */);
>>
>> I don't think we want two threadings so close together.  It makes
>some sense
>> to have a threading _after_ DOM but before VRP (DOM cleaned up the
>IL).
>That one is, IMHO, the least useful.  I haven't done any significant 
>analysis of this specific instance though to be sure.  The step you saw
>
>was meant to largely preserve behavior.  Further cleanups are
>definitely 
>possible.
>
>The most common case I've seen where the DOM/VRP make transformations 
>that then expose something useful to the backward threader come from 
>those pesky context sensitive equivalences.
>
>We (primarily Andrew, but Aldy and myself are also involved) are
>looking 
>at ways to more generally expose range information created for these 
>situations.  Exposing range information and getting it more precise by 
>allowing "unnecessary copies" or some such would eliminate those cases 
>where DOM/VRP expose new opportunities for the backwards jump threader.
>
>
>
>
>>
>> So that would leave two from your four passes and expose the
>opportunity
>> to re-add one during early-opts, also after FRE.  That one should be
>> throttled down to operate in "-Os" mode though.
>I'll take a look at them, but with some personal stuff and PTO it'll 
>likely be a few weeks before I've got anything useful.
>
>>
>> So, can you see what removing the two threading passes that don't
>make
>> sense to me do to your statistics?  And check whether a -Os-like
>threading
>> can be done early?
>Interesting you should mention doing threading early -- that was one of
>
>the secondary motivations behind getting the backwards threading bits 
>out into their own pass, I just failed to mention it.
>
>Essentially we want to limit the backwards substitution to single step 
>within a single block for that case (which is trivially easy).  That 
>would allow us to run a very cheap threader during early optimizations.

Just do double check - the pass does both forward and backward threading and 
DOM/VRP now do neither themselves?

Richard.

>Jeff

Re: Moving backwards/FSM threader into its own pass

[Jeff Law]

On 05/30/2016 03:16 AM, Richard Biener wrote:


Ok, but the placement (and number of) threading passes then no longer depends
on DOM/VRP passes - and as you placed the threading passes _before_ those
passes the threading itself does not benefit from DOM/VRP but only from
previous optimization passes.
Right.  Note that number of passes now is actually the same as we had 
before, they're just occurring outside DOM/VRP.


The backwards threader's only dependency on DOM/VRP was to propagate 
constants into PHI nodes and to propagate away copies.  That dependency 
was removed.





I see this as opportunity to remove some of them ;)  I now see in the main
optimization pipeline

  NEXT_PASS (pass_fre);
  NEXT_PASS (pass_thread_jumps);
  NEXT_PASS (pass_vrp, true /* warn_array_bounds_p */);

position makes sense - FRE removed redundancies and fully copy/constant
propagated the IL.

  NEXT_PASS (pass_sra);
  /* The dom pass will also resolve all __builtin_constant_p calls
 that are still there to 0.  This has to be done after some
 propagations have already run, but before some more dead code
 is removed, and this place fits nicely.  Remember this when
 trying to move or duplicate pass_dominator somewhere earlier.  */
  NEXT_PASS (pass_thread_jumps);
  NEXT_PASS (pass_dominator, true /* may_peel_loop_headers_p */);

this position OTOH doesn't make much sense as IL cleanup is missing
after SRA and previous opts.  After loop we now have
We should look at this one closely.  The backwards threader doesn't 
depend on IL cleanups.  It should do its job regardless of the state of 
the IL.





  NEXT_PASS (pass_tracer);
  NEXT_PASS (pass_thread_jumps);
  NEXT_PASS (pass_dominator, false /* may_peel_loop_headers_p */);
  NEXT_PASS (pass_strlen);
  NEXT_PASS (pass_thread_jumps);
  NEXT_PASS (pass_vrp, false /* warn_array_bounds_p */);

I don't think we want two threadings so close together.  It makes some sense
to have a threading _after_ DOM but before VRP (DOM cleaned up the IL).
That one is, IMHO, the least useful.  I haven't done any significant 
analysis of this specific instance though to be sure.  The step you saw 
was meant to largely preserve behavior.  Further cleanups are definitely 
possible.


The most common case I've seen where the DOM/VRP make transformations 
that then expose something useful to the backward threader come from 
those pesky context sensitive equivalences.


We (primarily Andrew, but Aldy and myself are also involved) are looking 
at ways to more generally expose range information created for these 
situations.  Exposing range information and getting it more precise by 
allowing "unnecessary copies" or some such would eliminate those cases 
where DOM/VRP expose new opportunities for the backwards jump threader.







So that would leave two from your four passes and expose the opportunity
to re-add one during early-opts, also after FRE.  That one should be
throttled down to operate in "-Os" mode though.
I'll take a look at them, but with some personal stuff and PTO it'll 
likely be a few weeks before I've got anything useful.




So, can you see what removing the two threading passes that don't make
sense to me do to your statistics?  And check whether a -Os-like threading
can be done early?
Interesting you should mention doing threading early -- that was one of 
the secondary motivations behind getting the backwards threading bits 
out into their own pass, I just failed to mention it.


Essentially we want to limit the backwards substitution to single step 
within a single block for that case (which is trivially easy).  That 
would allow us to run a very cheap threader during early optimizations.


Jeff

Re: Moving backwards/FSM threader into its own pass

[Richard Biener]

On Fri, May 27, 2016 at 6:30 PM, Jeff Law  wrote:
>
> It's been my plan since finally wrapping my head around Bodik's thesis to
> revamp how we handle jump threading to use some of the principles from his
> thesis.  In particular, the back substitution and simplification model feels
> like the right long term direction.
>
> Sebastian's FSM threader was the first step on that path (gcc-5). Exploiting
> that threader for more than just FSM loops was the next big step (gcc-6).
>
> This patch takes the next step -- dis-entangling that new jump threading
> code from the old threading code and VRP/DOM.
>
> The key thing to realize here is that the backwards (FSM) jump threader does
> not inherently need the DOM tables nor the ASSERT_EXPRs from VRP to do its
> job.  ie, it can and should run completely independently of DOM/VRP (though
> one day it may exploit range information that a prior VRP pass has
> computed).
>
> By moving the backwards threader into its own pass, we can run it prior to
> DOM/VRP, which allow DOM/VRP to work on a simpler CFG with larger extended
> basic blocks.

Ok, but the placement (and number of) threading passes then no longer depends
on DOM/VRP passes - and as you placed the threading passes _before_ those
passes the threading itself does not benefit from DOM/VRP but only from
previous optimization passes.

I see this as opportunity to remove some of them ;)  I now see in the main
optimization pipeline

  NEXT_PASS (pass_fre);
  NEXT_PASS (pass_thread_jumps);
  NEXT_PASS (pass_vrp, true /* warn_array_bounds_p */);

position makes sense - FRE removed redundancies and fully copy/constant
propagated the IL.

  NEXT_PASS (pass_sra);
  /* The dom pass will also resolve all __builtin_constant_p calls
 that are still there to 0.  This has to be done after some
 propagations have already run, but before some more dead code
 is removed, and this place fits nicely.  Remember this when
 trying to move or duplicate pass_dominator somewhere earlier.  */
  NEXT_PASS (pass_thread_jumps);
  NEXT_PASS (pass_dominator, true /* may_peel_loop_headers_p */);

this position OTOH doesn't make much sense as IL cleanup is missing
after SRA and previous opts.  After loop we now have

  NEXT_PASS (pass_tracer);
  NEXT_PASS (pass_thread_jumps);
  NEXT_PASS (pass_dominator, false /* may_peel_loop_headers_p */);
  NEXT_PASS (pass_strlen);
  NEXT_PASS (pass_thread_jumps);
  NEXT_PASS (pass_vrp, false /* warn_array_bounds_p */);

I don't think we want two threadings so close together.  It makes some sense
to have a threading _after_ DOM but before VRP (DOM cleaned up the IL).

So that would leave two from your four passes and expose the opportunity
to re-add one during early-opts, also after FRE.  That one should be
throttled down to operate in "-Os" mode though.

So, can you see what removing the two threading passes that don't make
sense to me do to your statistics?  And check whether a -Os-like threading
can be done early?

Thanks,
Richard.

> The removal of unexecutable paths before VRP also has the nice effect of
> also eliminating false positive warnings for some work Aldy is doing around
> out-of-bound array index warnings.
>
> We can remove all the calls to the backwards threader from the old style
> threader.  The way the FSM bits wired into the old threader caused redundant
> path evaluations.  That can be easily fixed with the FSM bits in their own
> pass.  The net is a 25% reduction in paths examined by the FSM threader.
>
> Finally, we ultimately end up threading more jumps.  I don't have the #s
> handy anymore, but when I ran this through my tester there was a clear
> decrease in the number of runtime jumps.
>
> So what are the downsides.
>
> With the threader in its own pass, we end up getting more calls into the CFG
> & SSA verification routines in a checking-enabled compiler.  So the
> compile-time improvement is lost for a checking-enabled compiler.
>
> The backward threader does not combine identical jump threading paths with
> different starting edges into a single jump threading path with multiple
> entry points.  This is primarily a codesize issue, but can have a secondary
> effect on performance.  I know how to fix this and it's on the list for
> gcc-7 along with further cleanups.
>
>
> Bootstrapped and regression tested on x86_64 linux.  Installing on the trunk
> momentarily.
>
> Jeff
>
> commit 35bd646a4834a68a49af9ccb5873362a0fc742ae
> Author: Jeff Law 
> Date:   Fri May 27 10:23:54 2016 -0600
>
> * tree-ssa-threadedge.c: Remove include of
> tree-ssa-threadbackward.h.
> (thread_across_edge): Remove calls to find_jump_threads_backwards.
> * passes.def: Add jump threading passes before DOM/VRP.
> * tree-ssa-threadbackward.c (find_jump_threads_backwards): Change
> argument to a basic block from an edge.  Remove tests which are
> 

Moving backwards/FSM threader into its own pass

[Jeff Law]

It's been my plan since finally wrapping my head around Bodik's thesis 
to revamp how we handle jump threading to use some of the principles 
from his thesis.  In particular, the back substitution and 
simplification model feels like the right long term direction.


Sebastian's FSM threader was the first step on that path (gcc-5). 
Exploiting that threader for more than just FSM loops was the next big 
step (gcc-6).


This patch takes the next step -- dis-entangling that new jump threading 
code from the old threading code and VRP/DOM.


The key thing to realize here is that the backwards (FSM) jump threader 
does not inherently need the DOM tables nor the ASSERT_EXPRs from VRP to 
do its job.  ie, it can and should run completely independently of 
DOM/VRP (though one day it may exploit range information that a prior 
VRP pass has computed).


By moving the backwards threader into its own pass, we can run it prior 
to DOM/VRP, which allow DOM/VRP to work on a simpler CFG with larger 
extended basic blocks.


The removal of unexecutable paths before VRP also has the nice effect of 
also eliminating false positive warnings for some work Aldy is doing 
around out-of-bound array index warnings.


We can remove all the calls to the backwards threader from the old style 
threader.  The way the FSM bits wired into the old threader caused 
redundant path evaluations.  That can be easily fixed with the FSM bits 
in their own pass.  The net is a 25% reduction in paths examined by the 
FSM threader.


Finally, we ultimately end up threading more jumps.  I don't have the #s 
handy anymore, but when I ran this through my tester there was a clear 
decrease in the number of runtime jumps.


So what are the downsides.

With the threader in its own pass, we end up getting more calls into the 
CFG & SSA verification routines in a checking-enabled compiler.  So the 
compile-time improvement is lost for a checking-enabled compiler.


The backward threader does not combine identical jump threading paths 
with different starting edges into a single jump threading path with 
multiple entry points.  This is primarily a codesize issue, but can have 
a secondary effect on performance.  I know how to fix this and it's on 
the list for gcc-7 along with further cleanups.



Bootstrapped and regression tested on x86_64 linux.  Installing on the 
trunk momentarily.


Jeff
commit 35bd646a4834a68a49af9ccb5873362a0fc742ae
Author: Jeff Law 
Date:   Fri May 27 10:23:54 2016 -0600

* tree-ssa-threadedge.c: Remove include of tree-ssa-threadbackward.h.
(thread_across_edge): Remove calls to find_jump_threads_backwards.
* passes.def: Add jump threading passes before DOM/VRP.
* tree-ssa-threadbackward.c (find_jump_threads_backwards): Change
argument to a basic block from an edge.  Remove tests which are
handled elsewhere.
(pass_data_thread_jumps, class pass_thread_jumps): New.
(pass_thread_jumps::gate, pass_thread_jumps::execute): New.
(make_pass_thread_jumps): Likewise.
* tree-pass.h (make_pass_thread_jumps): Declare.

* gcc.dg/tree-ssa/pr21417.c: Update expected output.
* gcc.dg/tree-ssa/pr66752-3.c: Likewise.
* gcc.dg/tree-ssa/pr68198.c: Likewise.
* gcc.dg/tree-ssa/pr69196-1.c: Likewise.
* gcc.dg/tree-ssa/pr69270-3.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-2b.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-2g.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-2h.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-6.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-12.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-13.c: Likewise.
* gcc.dg/tree-ssa/vrp56.c: Likewise.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f04d26d..40bac96 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,16 @@
+2016-05-26  Jeff Law  
+
+   * tree-ssa-threadedge.c: Remove include of tree-ssa-threadbackward.h.
+   (thread_across_edge): Remove calls to find_jump_threads_backwards.
+   * passes.def: Add jump threading passes before DOM/VRP.
+   * tree-ssa-threadbackward.c (find_jump_threads_backwards): Change
+   argument to a basic block from an edge.  Remove tests which are
+   handled elsewhere.
+   (pass_data_thread_jumps, class pass_thread_jumps): New.
+   (pass_thread_jumps::gate, pass_thread_jumps::execute): New.
+   (make_pass_thread_jumps): Likewise.
+   * tree-pass.h (make_pass_thread_jumps): Declare.
+
 2016-05-27  Eric Botcazou  
 
* config/visium/visium-protos.h (split_double_move): Rename into...
diff --git a/gcc/passes.def b/gcc/passes.def
index 993ed28..3647e90 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -199,6 +199,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_return_slot);