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. Thus the scaling to offset for that. OTOH the backward threader does not have any means to count likely eliminated stmts, so it already accounts things as more expensive as the forward threader. 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. Richard. > > Jeff >
