Bounds propagation during sliding window optimization

[stevenraphael]

This PR makes it easier for Halide to prove that loop bounds are monotonically increasing/decreasing during the sliding window optimization by tracking overall bounds information for variables used in the loop bound expressions. It tracks bounds rather than attempting more aggressive simplification in order to avoid longer compile times. I found this issue when I tried to write a cascade of filters where the loop bound expressions got more complex after applying the sliding window optimization to each successive filter.

Checklist

• Tests added or updated (not required for docs, CI config, or typo fixes)
• Commits include AI attribution where applicable (see Code of Conduct)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@bd3a522). Learn more about missing BASE report.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #9170   +/-   ##
=======================================
  Coverage        ?   69.34%           
=======================================
  Files           ?      254           
  Lines           ?    78269           
  Branches        ?    18726           
=======================================
  Hits            ?    54278           
  Misses          ?    18495           
  Partials        ?     5496           

☔ View full report in Codecov by Sentry.
📢 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]

This is the sort of thing that can easily blow up exponentially (due to expand_expr). Could you try a stencil chain of depth 100, both with the schedule: f[i].store_root().compute_at(f.back(), y); and also f[i].store_root().compute_at(f[i+1], y)? Also try any other potentially-pathological cases you can think of.

[stevenraphael]

I will do that but I did not add any calls to expand_expr that were not there before. Maybe there's a risk that Halide can try to perform deep chains of sliding window optimizations with increasingly complex bounds exprs that it was unable to do previously without the bounds propagation?

[stevenraphael]

f[i].store_root().compute_at(f.back(), y) works both with and without the bounds propagation, but f[i].store_root().compute_at(f[i+1], y) does not work in either case.

[abadams]

I will do that but I did not add any calls to expand_expr that were not there before. Maybe there's a risk that Halide can try to perform deep chains of sliding window optimizations with increasingly complex bounds exprs that it was unable to do previously without the bounds propagation?

That is my concern, yes.

[abadams]

Can confirm the second option does not work on main anyway, alas (in the sense that sliding window doesn't happen), but please just check it compiles in roughly the same amount of time as main.

[stevenraphael]

I found a pathological case that gets apparently exponential complexity growth: fi = f[i - 1](x - 1) + f[i - 1](min(x + 1, 20)); f[i].store_root().compute_at(f.back(), y)