Re: Moving backwards/FSM threader into its own pass
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
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
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
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
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
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
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 > handled elsewhere. > (pass_d
