JIT: don't mark callees noinline for non-fatal observations with pgo #114821
Conversation
Some inline policy decisions are sensitive to the root method having valid PGO data. And sometimes the decision is that a particular callee can never be a viable inline. If so, the policy will have the runtime mark the method as `NoInlining` to short-circuit future inlining decisions and save some JIT throughput. But if the method had valid PGO data the policy may have made a different decision. By marking this method noinline, the JIT will immediately reject all future inline attempts (say from other calling methods with valid PGO data). For instance, without PGO, the policy may limit the number of basic blocks in a viable callee to 5. But with PGO the policy is willing to consider callees with many more blocks. In this PR we modify the reporting policy so that if TieredPGO is active, we only ever report back methods with truly fatal inlining issues, not just "informational" or "performance" issues, regardless of the state of the PGO data for the method being jitted.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
There was a problem hiding this comment.
Pull Request Overview
This PR refines the JIT inline reporting policy when TieredPGO is active, ensuring that methods are only marked as NoInlining for truly fatal inlining issues.
- Introduces a dynamic PGO check via fgPgoDynamic.
- Suppresses NoInlining marking for non-fatal observations when TieredPGO is active.
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
@EgorBo PTAL Not sure how widely this happens. I noticed With this PR we still see the inline fail, but we no longer block future attempts |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
I remember I accidentally broke the noinline propagation logic and that resulted into ~40 benchmarks improvements in dotnet/performance, I reverted it because it was not intentional, let's see how this goes. I presume it might impact TP, though. |
|
Failures are timeouts |
Some inline policy decisions are sensitive to the root method having valid PGO data. And sometimes, with invalid PGO data, the decision is that a particular callee can never be a viable inline. If so, the policy will have the runtime mark the method as
NoInliningto short-circuit future inlining decisions and save some JIT throughput.But if the method had valid PGO data the policy may have made a different decision. By marking this method noinline, the JIT will immediately reject all future inline attempts (say from other calling methods with valid PGO data).
For instance, without PGO, the policy may limit the number of basic blocks in a viable callee to 5. But with PGO the policy is willing to consider callees with many more blocks.
In this PR we modify the reporting policy so that if TieredPGO is active, we only ever report back methods with truly fatal inlining issues, not just "informational" or "performance" issues, regardless of the state of the PGO data for the method being jitted.