[llvm] [SCEV] Avoid recursion in PHI handling in more cases. (PR #215910)

Eli Friedman via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 18 15:52:13 PDT 2026


efriedma-quic wrote:

I tried adding back the early returns, it doesn't help.  https://llvm-compile-time-tracker.com/compare.php?from=13034ef965533cdc9d215a8d506ee8250ead972b&to=7c44c957c05755d0693eb286aadd1441ad1f9acf&stat=instructions%3Au#

I can maybe make valuesForAddRecFromPHI() itself slightly cheaper by special-casing two-entry PHIs; if a loop header has two predecessors, one of them must be the immediate dominator, and the immediate dominator is cheap to compute because it's stored directly in the domtree.  But I doubt that's actually the issue here.

I suspect the real cost is actually the cost of constructing the SCEV for the start value: createAddRecFromPHI puts off calling `getSCEV(StartValueV)` until it's already proven it can analyze the backedge PHI.  So this patch is constructing a SCEV for a value where we wouldn't normally compute the SCEV at all; we'd just leave the PHI as a SCEVUnknown and ignore the initial value.

This is problematic because https://github.com/llvm/llvm-project/pull/215658 specifically relies on computing the initial value first: we need to construct the SymbolicName SCEV for the outer loop PHI before the SymbolicName SCEV for the inner loop.  I'm not sure how to get that benefit without the performance cost.  Maybe we could do a quick scan to rule out values where the backedge value obviously won't allow forming an AddRec.

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


More information about the llvm-commits mailing list