[llvm] [BFI] Solve irreducible SCCs instead of splitting their headers (PR #215170)
via llvm-commits
llvm-commits at lists.llvm.org
Sat Aug 15 11:33:53 PDT 2026
spupyrev wrote:
The patch seems useful, but I’d like to better understand how it relates to `iterativeInference` and what's the desired end state. `iterativeInference` solves the same underlying problem globally and, based on the numbers here, provides substantially larger accuracy improvements. Where it actually runs, I don’t see evidence that this patch improves the final result further.
One thing that stands out is that `needIterativeInference()` currently requires `hasProfileData()`, but the implementation of `iterativeInference` itself does not consume profile counts; it uses the CFG, BPI probabilities, and the existing BFI result as the initial estimate. So `hasProfileData()` is a safety gate, not a restriction; we can drop it if there is a use case. Relatedly, what is the motivation for improving irreducible BFI specifically for functions without profile data? Statically guessed counts are anyway close-to-garbage; perhaps you have a use case?
I don’t think the 200-iteration compile-time experiment answers whether `iterativeInference` could be enabled more broadly. An iteration here is a full SCC sweep, whereas `iterativeInference` uses "lazy" iterations (via maintaining an active worklist) where one iteration updates one block, and `1000 * block_count` is only a worst-case cap. It would be useful to measure the actual compile-time impact of removing the `hasProfileData()` restriction while retaining the irreducible-CFG condition.
Regarding `findReachableBlocks`: I think its exclusion of nodes that cannot reach an exit is intentional rather than a limitation. For a reachable closed/non-returning SCC, expected execution counts per function entry are unbounded, so there is no finite solution to the usual flow equations for those nodes. The local SCC solver can still produce a distribution of weights inside such a component, but I’m not sure that should be considered a more accurate BFI result rather than a heuristic for a case where finite BFI is not well-defined.
So, I’m trying to understand the intended end state:
* PR215170 alone,
* PR215170 plus `iterativeInference` enabled more broadly, or
* the structural cleanup from PR215170, with `iterativeInference` providing the frequency refinement.
https://github.com/llvm/llvm-project/pull/215170
More information about the llvm-commits
mailing list