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.
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
