On Wed, Jul 9, 2025 at 3:06 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 7/9/25 6:53 AM, Richard Biener wrote: > > On Wed, Jul 9, 2025 at 2:16 PM Jeff Law <jeffreya...@gmail.com> wrote: > >> > >> > >> > >> On 7/9/25 12:27 AM, Richard Biener wrote: > >>> The following changes the percentage that determines how many > >>> stmts are allowed for backwards jump threading from 50 to 54, > >>> enabling the missed jump threading observed in PR109893. > >>> > >>> Bootstrapped and tested on x86_64-unknown-linux-gnu. It seems that > >>> at least backward threading is prone to profile mismatches, I've > >>> altered two testcases to deal with new ones to pop up (definitely > >>> latent issues). > >>> > >>> OK? > >>> > >>> PR tree-optimization/109893 > >>> * params.opt (fsm-scale-path-stmts): Change from 50 to 54. > >>> > >>> * gcc.dg/tree-ssa/pr109893.c: New testcase. > >>> * gcc.dg/tree-prof/cmpsf-1.c: XFAIL. > >>> * gcc.dg/tree-ssa/pr109893.c: Remove scan on no profile > >>> mismatches. > >> My recollection is the scaling factor was set one based on some old PR > >> where code size exploded and wasn't really tuned further after that. If > >> the new value is working better, then that's obviously fine with me. > >> Ideally we'd just get rid of the magic ratio.... > > > > Yes, there's some hand-waving about the forward threader having ways > > to re-use copied blocks but the backward threader does not. > That's absolutely correct. Essentially the forward threader creates one > jump thread path for each final destination. Then all the incoming > edges are redirected to the appropriate copy. The backwards threader > makes a copy for each jump thread path discovered.
ISTR the backwards threader simply cancels paths that had blocks in common with another jump thread (that happened to be materialized first). But maybe it's less strict than that. It cancels things in too many places and while it collects all opportunities upfront it doesn't have any global limit on the amount of copying it does (and do pruning based on such limit in any sensible order, of course). Richard. > > > > > > Unless somebody is going to spend time cleaning things up further > > (we've talked about getting rid of the forward threader), this is what I > > have to offer. > I'd still like to see the forward threader go away. I haven't done any > evaluation on what needs to happen to realize that goal in years though. > > jeff >
