[all-commits] [llvm/llvm-project] d2d86d: [ConstraintElim] Cache decompositions to avoid com...
Florian Hahn via All-commits
all-commits at lists.llvm.org
Tue Sep 22 14:31:12 PDT 2026
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: d2d86dc298e6d10f8e019448061316b4d046caf9
https://github.com/llvm/llvm-project/commit/d2d86dc298e6d10f8e019448061316b4d046caf9
Author: Florian Hahn <flo at fhahn.com>
Date: 2026-09-22 (Tue, 22 Sep 2026)
Changed paths:
M llvm/lib/Transforms/Scalar/ConstraintElimination.cpp
A llvm/test/Transforms/ConstraintElimination/decompose-sub-chain-compile-time.ll
Log Message:
-----------
[ConstraintElim] Cache decompositions to avoid compile-time blow-up. (#225207)
With the recent improvements to isKnownNoWrap, we now can call decompose
again on (sub-) expressions multiple times for a given query.
In some cases, this can lead to exponential compile-time increases, as
as each decompose sub-call can lead to many more repeated decompose
calls via isKnownNoWrap.
For the test case in the patch, compile-time without the patch is > 250s
on my system, vs < 0.5s with the patch.
The caching is mostly beneficial to avoid exponential compile-time, and
does not translate to compile-time improvements in
https://llvm-compile-time-tracker.com/compare.php?from=150f8999285d07bdebc6a73dfdeae520dbdf1468&to=5f64294359fb513d62e257e95988779b2d5b8d77&stat=instructions:u.
Note that mayLookThrough is needed to avoid going through the cache
unnecessarily for leave nodes. Without that bypass, I measured a
noticeable compile-time increase (around +0.05% geomean).
The test case for the patch is synthetic, but I hit the same issue on
llvm-opt-benchmark-nightly for a patch adding a new rule to
isKnownNoWrap.
PR: https://github.com/llvm/llvm-project/pull/225207
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list