[llvm] [InstCombine] Push freeze through non-recurrence PHIs (PR #157678)
Paul Walker via llvm-commits
llvm-commits at lists.llvm.org
Wed Nov 19 05:22:50 PST 2025
paulwalker-arm wrote:
Hi @c-rhodes, I've taken a look at the PR and I think the story goes something like this:
There are a couple of "push freeze through PHIs" transformations that are fairly restricted and neither of which round-trip the combiner but instead process whole IR chains for as long as the freeze can be pushed from child to parent.
You are adding a similar transformation for the cases not handled by the existing ones. This has the effect of chaining your transformation to the existing ones by round-tripping the combiner. Specifically, with this PR you'll push a freeze through a reduction PHI and stop, then you push that freeze through non-reduction PHIs and stop, then you push that freeze through a reduction PHI and stop...and on and on.
This is not necessarily bad but the "hang" case has a chain of repeated reduction loops. This is relevant because (I think) instcombine processes blocks in reverse post order, which means you end up processing the same PHIs over and over again as you push freeze instructions from the blocks that occur later and later in the chain.
I'm no mathematician but crudely I think this pathological case is turning the original problem of iterating between the multiple PHI transformations (N seconds) into an N! seconds problem.
Possible solutions are:
1. Try to combine the "push freeze through PHIs" transformations into one. This was suggested above and will remove the round-tripping problem, but you'll still suffer from repeatedly processing the same PHIs.
2. and/or Maintain a cache of PHIs (or Instructions?) that have already had freeze instructions pushed through them. This can then act as an early exit by feeding into the question used by pushFreezeToPreventPoisonFromPropagating when adding things to the worklist.
3. I suspect this is a non-starter but perhaps freeze removal should be a dedicate pass?
Not sure what others think, but (2) feels like the easier starting point? and depending on the result might remove the need for (1).
https://github.com/llvm/llvm-project/pull/157678
More information about the llvm-commits
mailing list