[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