I just have a few high level comments. On Tue, Aug 16, 2022 at 4:05 PM Richard Biener <rguent...@suse.de> wrote: > > The following refactors profitable_path_p in the backward threader, > splitting out parts that can be computed once the exit block is known, > parts that contiguously update and that can be checked allowing > for the path to be later identified as FSM with larger limits, > possibly_profitable_path_p, and final checks done when the whole > path is known, profitable_path_p.
I thought we were removing references to FSM, as they were leftovers from some previous incarnation. For that matter, I don't think I ever understood what they are, so if we're gonna keep them, could you comment what makes FSM threads different from other threads? In your possibly_profitable_path_p function, could you document a bit better what's the difference between profitable_path_p and possibly_profitable_path_p? > > I've removed the back_threader_profitability instance from the > back_threader class and instead instantiate it once per path > discovery. I've kept the size compute non-incremental to simplify > the patch and not worry about unwinding. > > There's key changes to previous behavior - namely we apply > the param_max_jump_thread_duplication_stmts early only when > we know the path cannot become an FSM one (multiway + thread through > latch) but make sure to elide the path query when we we didn't > yet discover that but are over this limit. Similarly the > speed limit is now used even when we did not yet discover a > hot BB on the path. Basically the idea is to only stop path > discovery when we know the path will never become profitable > but avoid the expensive path range query when we know it's > currently not. > > I've done a few cleanups, merging functions, on the way. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > Statistics show an overall slight increase in threading but > looking at different files theres noise up and down. That's > somewhat expected since we now are applying the "more correct" > limits in the end. Unless I made big mistakes of course. > > The next thing cost-wise would be to raise the backwards > threading limit to the limit of DOM so we don't get > artificial high counts for that. The DOM threader has limits? I thought most of those limits were just due to the fact that it couldn't determine long enough paths? Either way, I like that we're merging the necessary forward threader bits here, in preparation for its demise ;-). Looks good. Thanks. Aldy
