Allow the simplifier to use facts in its can_prove() predicates.

[mcourteaux]

Problem

Rewrite rules can only use what the simplifier knows through can_prove(cond, this), which builds a fresh Expr and recursively simplifies it. That ignores the learned facts (max(x, y) doesn't fold under if (y <= x)), and it recurses without bound when the rule's LHS matches something built while proving its own predicate: apps/lens_blur did not finish lowering (killed after 52 CPU-minutes).

What this PR does

Facts become bounds on differences. Every comparison the simplifier learns (if conditions, asserts, require, loop bounds) is stored as a ConstantInterval on ca * a - cb * b: a < b gives <= -1, !(a < b) gives >= 0, a == b gives 0, a != b removes the point 0. Constant add/mul/div terms are peeled off both sides and the coefficients reduced to a coprime pair, so x < y / 8, 8 * x < y, and 3 * x - 6 * y vs 2 * x - 4 * y all meet at one record. A bitmask over hashed pairs rejects most lookups before any record is read.

Rules read the facts without building IR. min_diff(x, y, this) / max_diff(...) and linear_min_diff(x, c0, y, c1, this) / linear_max_diff(...) are rewrite predicates that inspect the nodes a rule has already bound (wildcards only, enforced by static_assert). Users:

• min/max pick a side when the facts order the operands (Simplify_Min.cpp, Simplify_Max.cpp).
• max(x * c0, y) / c0 -> x and the min variant (Simplify_Div.cpp).
• The bounds of Add/Sub intersect with the known difference, so max(x - 5 * y, 0) folds from 5 * y < x through the ordinary bounds machinery, with no rule per shape.

can_prove gets a depth limit (max_can_prove_depth = 2), checked where the recursion happens so it covers existing rules. A regression test in simplify.cpp hangs without it.

Facts must be simplified before they are learned (learn_true/learn_false assert on >/>=), so they are stored in the form the simplifier produces when it meets them. The assumptions argument of simplify() inherits this requirement.

Bounds inference: NameGuardedIndices (src/Bounds.cpp)

Why it's there. With facts, the simplifier removes a clamp that an enclosing if makes redundant. hannk's max pool reads input(clamp(x * s + r.x, min_x, max_x)) under where(min_x <= x * s + r.x && ...). Bounds inference derives the input's required region from the IR after the first simplification (image checks, allocation bounds, storage folding), and BoxesTouched only uses an if condition by solving it for one variable at a time. It can't bound x * s + r.x as a whole, so once the clamp was gone the region asked of input grew to whatever the unclamped index could reach, and the pipeline failed its own bounds check.

What it does. Inside boxes_touched, every compound index in an if's body that the condition also mentions gets a name, and the condition is repeated in terms of it:

if (min_x <= x * s + r.x) { f(x * s + r.x); g(r.x) }

becomes

let t = x * s + r.x in
if (min_x <= x * s + r.x) {   // still bounds x and r.x on their own, for g
  if (min_x <= t) {           // bounds the index as a whole, for f
    f(t); g(r.x)
  }
}

Why it works. t is a let, so BoxesTouched has its bounds in scope and the inner condition solves for it like any variable, giving f's index exactly the bound the clamp used to give. The original condition stays outside so the component variables are still trimmed for every other index they appear in (the dependent-let machinery recomputes t from the trimmed components, so the two combine). The rewrite is applied to the copy boxes_touched takes by value and never reaches the lowered IR. Lowering time is unchanged within noise (+0.8% over 18 generators).

Tests: bounds_of_compound_index_from_where.cpp covers the hannk shape, a scaled and a halved index, and two cases where a second input is read at only part of the named index.

Compile-time impact

Lowering only (-e stmt, wall clock, 5 reps, machine otherwise idle), 75 apps/ generators, this branch with main (d82d5a3) merged, against that main: +2.0% in total (9510 ms vs 9704 ms; sum of per-generator minimums also +2.0%). local_laplacian +11% and stencil_chain +6% are the largest costs; dgemv -25% and sgemv -14% go the other way, from loop trimming. Summed over all generators the cost sits in the simplifier-driven passes (second simplification +17%, partitioning loops +15%, removing dead allocations +12%, finding intrinsics +10%, vectorizing +11%), where every Add, Sub, min and max inside a fact scope now asks the fact table once.

The fact table is chained per bucket of the pair's hashes, so a query reads only the records that can be about its pair. A pipeline's image checks alone leave hundreds of facts in scope for its whole body, and a linear scan over them was the single hottest function when lowering resnet_50 (+25%, for byte-identical output); it is now +2%. The full per-generator table and pass breakdown:

Lowered IR: 39 of 75 pipelines are byte-identical, 3 differ only in temporary numbering, 33 change. Where operator counts move, they go down: dgemv -15 max -75 min, sgemv -17 max -63 min, sgemm/dgemm -11 max -13 min -11 / each, hannk/DepthwiseConv -6 if, halide_blur -2 if -4 min, fft -9 max. In local_laplacian (-32 max, -44 min) and interpolate (-21 max, -6 min) the folded max/min were the pyramid-level bounds, each a min/max of two affine chains over one variable (min(gPyramid1.s0.v1.min*2 - 1, output.min.1)). Once decided, every level collapses to a single chain like ((output.min.1 - 127)/128)*4, and the simplifier's let peeling then substitutes such a chain at each use instead of keeping the let, so the text gains / (+105 and +38) while getting shorter overall. LLVM folds most of that back (29 more sar, +0.4% text in the object), and run time is unchanged: local_laplacian at 2048x1536, 8 levels, is 24.0-24.7 ms on main and 23.6-24.3 ms here.

Behaviour change

max(x * 8, y) / 8 now folds to x given y / 8 <= x. simplify.cpp previously asserted it stays put; that was a limitation, not a truth.

Checklist

• Tests added or updated (not required for docs, CI config, or typo fixes)
• Documentation updated (if public API changed)
• Python bindings updated (if public API changed)
• Benchmarks are included here if the change is intended to affect performance.
• Commits include AI attribution where applicable (see Code of Conduct)

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 85.95388% with 67 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.99%. Comparing base (35b7aa6) to head (2f35b21).

Files with missing lines	Patch %	Lines
src/Simplify.cpp	80.82%	40 Missing and 25 partials ⚠️
src/Simplify_Internal.h	88.88%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9400      +/-   ##
==========================================
+ Coverage   70.86%   70.99%   +0.13%     
==========================================
  Files         261      261              
  Lines       79989    80459     +470     
  Branches    19494    19642     +148     
==========================================
+ Hits        56687    57125     +438     
- Misses      17470    17492      +22     
- Partials     5832     5842      +10     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[abadams]

Was this the one that inflated the lowering time of lens_blur? Is this superseded by your approach in aligned splits take 2?

[abadams]

Some more data: yesterday in a research branch I came across a case where max(x, y) was not simplifying inside an if (x <= y) branch, and it was causing wmma ops to fail to be extracted. This is a case we need to handle, we just need to figure out how to do it without increasing compile times.

[abadams]

I think an approach to make this fast might be to define an operator< that can compare IRMatcher patterns to Exprs, so that the pattern can be looked up in the set of known facts without constructing an IR node, rather than needing to build an Expr just to do the lookup.

[mcourteaux]

Was this the one that inflated the lowering time of lens_blur? Is this superseded by your approach in aligned splits take 2?

This indeed did slow down lens blur by 10% more ore less. It's not superseded: take 2 just works around the simplification issue by using .bound_extent() and .bound_storage().

Some more data: yesterday in a research branch I came across a case where max(x, y) was not simplifying inside an if (x <= y) branch, and it was causing wmma ops to fail to be extracted. This is a case we need to handle, we just need to figure out how to do it without increasing compile times.

🤝

I think an approach to make this fast might be to define an operator< that can compare IRMatcher patterns to Exprs, so that the pattern can be looked up in the set of known facts without constructing an IR node, rather than needing to build an Expr just to do the lookup.

That sounds like a decent approach! Feel free to take over this branch!

[mcourteaux]

What if instead, we special handle the generic-form max(x, y) and min(x, y) above the chain of rewrite rules, by doing a fact_lookup_comparison(x, y) that returns an enum: NOTHING_KNOWN, LT, LE, EQ, GE, GT.

As such, no known_true() is called for every Max node, and no new Expr is constructed.

We can keep the more expensive machinery for non-trivial rules, such as the ones now in Simplify_Div, which wouldn't trigger for every Max/Min node, because the LHS of the rewrite rule is more specific:

 has_facts() &&
    (rewrite(max(x * c0, y) / c0, x, c0 > 0 && known_true(x >= y / c0, this)) ||
     rewrite(max(y, x * c0) / c0, x, c0 > 0 && known_true(x >= y / c0, this)) ||
     rewrite(min(x * c0, y) / c0, x, c0 > 0 && known_true(x <= y / c0, this)) ||
     rewrite(min(y, x * c0) / c0, x, c0 > 0 && known_true(x <= y / c0, this)))

The existing known_true() would then call out to fact_lookup_comparison().

Later, when we learn_true(some_expr % some_other_expr == 0) for example, we can have special handling in Simplify_Mod with a fact_lookup_modrem(x, y), which can return more info specific to those kind of facts.

[mcourteaux]

Offline discussion with @abadams, with some ideas going back and forth, Andrew proposed to:

record a list of (Expr, Expr, ConstantInterval), where the interval is constant bounds on the difference between the two Exprs. Then in the predicate you could query the lower or upper bound of the difference.

As such, we can have a function that return ConstantBounds for the difference between two Expr. Then you can write predicates like this:

rewrite(max(x, y), x, min_diff(x, y, this) >= 0) // because x - y >= 0, we know that x >= y.

[mcourteaux]

@abadams Ready for review. Original post updated. This was all Claude with a lot of guidance, so perhaps a lot of comments are still too verbose, and maybe a few names left and right could be better. However, I think the approach is good.

Performance impact of the lookups was real, so we iterated a bit to make them even faster using a cheap hashing scheme. This was the initial histogram of number of facts present, during fact lookup happening within lens_blur:

The massive amount of lookups when there were no facts was fixed after this chart was made. Claude argued by doing some analysis on different runs of retired instruction count that a std::map would not make things faster; not actually measured yet.

[abadams]

Is it necessary to have this and ScaledDiffBound? Can't ScaledDiffBound just represent these cases? The helpers min_diff and max_diff could remain

[mcourteaux]

Renamed to LinearDiffBound, and deleted the other.

[abadams]

This is very unfortunate. What precisely breaks without this intentional reduction in simplifier strength? Can those passes just instead leverage the simplifier, e.g. by inheriting from it?

[mcourteaux]

BoundsInference does not take an injected if from a RDom where-clause into account when the index Expr is a compound Expr of 2+ variables (e.g., x*stride + r.x). The injected if-guard from the where clause gets rewritten to a solved Expr for the innermost loop variable, which causes the bound on the compound statement to be rewritten from x*stride + r.x < upper to x < (upper - r.x) / stride, which is now no longer picked up as a bound on the compound Expr.

The hannk generator was aware of this limitation, and introduces a redundant clamp, which is supposed to help out bounds inference see (i.e., just give it) the bound of this compound index Expr.

Now, because the new simplifier strength, the redundant clamp is now simplified away rightfully, because it's is sitting within the if-guard of the where clause.

I 100% agree that ScopedRegionsInferred is not the right solution to this problem.

[mcourteaux]

@abadams I think the solution Fable found is really neat: NameGuardedIndices. Whenever a compound index-Expr is encountered in an enclosing if-guard, it injects a LetStmt replacing the compound Expr with a new temporary. This way, the index-Expr is again a single variable, and the existing solve-machinery now works on the new single-Variable.

[abadams]

If this shows up as hot it the profiler, it may be worth a fast path for powers of two

[abadams]

Can d be negative? Generally we use div_imp and mod_imp in logic like this because of rounding direction issues

[mcourteaux]

Good to know about these helpers. Reimplemented using those.

[abadams]

I think this is for cases where you learn x != y? Is there a real payoff from supporting these? I wonder if it's worth it.

[mcourteaux]

Well, I thought about adding those, as we tend to often see tail conditions like

if (out.extent.0 % 10 != 0) {
   // some tail
}

This is not a good reason, as that's just the use case for RoundUp, but at least an inequality does appear.

Not sure if we will ever learn inequalities. Seemed like a cheap enough addition, so I added it.

[abadams]

Hasn't everything passed to learn_true/learn_false already been mutated? This should be dead code

[mcourteaux]

It seems like you're right. It is dead code from within the compiler. However, the simplifier correctness test passes assumptions directly to the simplifier, which are not in their canonical order. I added a call to simplify() for every assumption in the check_with_assumptions helper of the tests.

The canonicalization is replaced by an internal_assert.

[abadams]

Would it be cleaner to put "this" in the IRMatcher state?

[mcourteaux]

I propose a separate PR for this, as there are many can_prove() rules I'd like to not touch in this PR.

[abadams]

#9448 may make the lowering time cost look better, by taming bgu

[abadams]

I made a bunch of relatively minor comments, and I have one larger concern - intentionally limiting the performance of the simplifier before a certain point in lowering feels it should not be necessary, and hints at a deeper problem with making the simplifier more powerful - other passes can no longer keep up. Perhaps those other passes could leverage or be built on top of the simplifier instead.