Repository navigation
Conversation
Contributor
|
Can this address #9375 ? |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## abadams/sliding_window_rewrite #9633 +/- ##
==================================================================
+ Coverage 72.92% 72.99% +0.07%
==================================================================
Files 267 267
Lines 83864 84273 +409
Branches 20615 20720 +105
==================================================================
+ Hits 61156 61517 +361
- Misses 16256 16264 +8
- Partials 6452 6492 +40 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Func::slide(consumer, var) names a dimension of a consumer to slide along, rather than leaving sliding window to pick a loop. The dimension may have been split, in which case it has no loop of its own, only a let built from the loops it was split into. Sliding and storage folding both work over such a let as well as over a loop, warming up by rewinding the outermost loop the dimension is built from. Schedule validation checks that a slid dimension steps through its values in order (serial, adjacent loops with constant split factors and no tail except on the outermost), that the storage lives outside every loop the dimension spans, and that the Func is computed inside them. The sliding window fuzzer sometimes names y, which is split, or both x and y. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
DerivativeBounds only handled a Mul whose other operand was constant and a Div by a constant. Use constant_integer_bounds on a var-independent factor or denominator so that e.g. x / max(k, 1) is recognized as monotonic increasing. This lets sliding window slide over such footprints. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ctive Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
A Func told to slide over a dimension silently computed its whole region on every iteration if the window couldn't actually slide there. Make that a user error that says why. The fuzzer now only asks for slides that are possible: the region required has to move with exactly the dimension named, every consumer has to read more than one value along it, no update can scatter along it, and no consumer stored outside the loops it is split into may slide over those loops first. Its piecewise-affine coordinate with two slopes is now written as a max, which bounds inference handles precisely. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ctive Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…irective Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ctive Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ctive # Conflicts: # src/SlidingWindow.cpp # test/correctness/sliding_window.cpp
A slide over a dimension built from split loops, where the Func is computed outside one of those loops, used to be silently ignored. It is now a user error that suggests sliding over the outer loop instead, or computing the Func at or inside the inner one. Lowering can now assume that the producer is always inside every loop its dimension is built from. Also tests a named slide through a specialized consumer. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Each schedule now aims to slide over y, over x and y, or in registers, and the fuzzer checks that every slid producer stores no more than its exact footprint plus the warm-up, so it catches slides that silently fail to happen or that recompute. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
abadams
marked this pull request as draft
November 5, 2026 21:07
…ctive # Conflicts: # src/SlidingWindow.cpp
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sliding window has numerous bugs relating to the interaction between the two kinds of sliding (loop unwinding vs adding selects). One known one was #8140 , but there were more. This PR adds a fuzzer for sliding window schedules and rewrites the sliding window pass to pass the fuzz tests. For review it's probably easier to just read the new version of the file, rather than looking at diffs. Several rounds of refactoring were done to try to make it easier to understand.
Separately, sliding window has long had an annoying limitation. When sliding and folding are combined, you get modulos due to the circular buffers. One might like to remove these modulos by unrolling the loop by the same factor, but if you do this you just get a different modulo, because sliding and folding can only slide over either the outer loop or the inner loop, not the loop you just split. This PR adds Func::slide, which lets you slide over a named Var, even if that Var has been split. For example, this is legal:
The producer can slide over xo, which is a transient loop that only existed in the middle of the chain of splits. It does this by jointly considering the loops it was split into - xoo and xoi. These loops must still appear in the schedule in order with no other loops in between. More commonly you would slide the producer over x - one of the original Vars. Using this directive lets you slide over x and also unroll the consumer's loop over x without changing the meaning of the slide.
This change is necessary for inductive Funcs (#8878) to be truly useful, because those rely critically on sliding window working well.
I can break this into two PRs if helpful. However Func::slide required a rewrite on top of the rewrite already done to fix the bugs, and I don't want to ask reviewers to review two rewrites of the same code. I would construct the stack by deleting the new feature from this branch, which might make some of the changes look pointless.
EDIT: Broken into multiple PRs. This one now just adds the slide directive and the ability to slide over spit loops. It is stacked on the rewrite and fuzzer.