[llvm] [InstCombine][NFC] Change the order of checks in SliceUpIllegalIntegerPHI for faster compile time. (PR #183726)

via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 27 20:50:55 PDT 2026


XinlongZHANG-Bob wrote:

> In particular, are you sure that you are fixing a real problem that exists on `main` here. I believe the quadratic complexity in this code has already been fixed by [5334c51](https://github.com/llvm/llvm-project/commit/5334c5148637dc58ae0e527b7b2c7c0569542271), it's not really obvious to me under what circumstances your patch would help further.

@nikic @dtcxzyw Thank you both for running the tracker!

I agree that on the public CTMark benchmark, the difference is within the noise margin (~0.00%). However, I would still like to advocate for this patch because we are seeing a significant, measurable compile-time improvement in our internal heavy-duty C++ workloads (which likely involve more complex CFGs or heavy exception handling).

Here is the build time data for one of our internal core modules:
* Baseline (before `5334c51`): 10m 49s
* Current `main` (with `5334c51` only): 9m 52s
* Current `main` + **This PR**: **9m 11s** (an additional ~40s / 7% improvement)

**Why this still helps:**
While `5334c51` fixed the quadratic append issue, the current code still iterates over `zip(PN->blocks(), PN->incoming_values())` to check for `invoke` instructions *before* checking the PHI users. Scanning incoming blocks/values can be expensive for PHIs with many incoming edges. 

By reordering the checks, we first filter PHIs based on their users (`trunc` or `trunc(lshr)`). This user check is much stricter and cheaper. We completely avoid scanning the incoming edges for `invoke`/`catchswitch` if the PHI doesn't even have the required users. In codebases with heavy EH pads or massive PHI nodes, this avoids a lot of unnecessary edge traversals.

Given that this PR is strictly neutral on CTMark (no regressions), improves the readability by decoupling the checks, and acts as a compile-time rescue for certain pathological cases, would you be open to accepting it?

https://github.com/llvm/llvm-project/pull/183726


More information about the llvm-commits mailing list