Fix read-after-write hazard analysis in storage folding #7910
+84
−9
Conversation
This file contains 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
In the following code:
let a = b in
X
let a = c in
Y
If Stmt X successfully had stores interleaved, it was re-nesting it like
so:
let a = b in
X
let a = c in
Y
This introduces a shadowed variable 'a', which is illegal at this stage
of lowering.
Fixes #7906
Also some drive-by fixes to earlier tests that had debugging code left
in.
Explicitly mark which loops get loop-carry-dependencies inserted by sliding window to assist storage folding. Storage folding needs to know about this so it doesn't try to fold in a way that invalidates these read-after-write dependencies. It currently tries to prove the absence of hazards with box_contains(box_provided, box_required), but this is sometimes incorrect because box_provided could be conservatively large, and the code it analyses might not actually provide (store to) all the required (loaded from) values. It's simpler for sliding window to just tell storage folding when it inserts loop-carry-dependencies, and this is most simply done directly in the IR itself. Fixes #7909
TH3CHARLie
approved these changes
Oct 23, 2023
|
LLVM failure opened as a bug here: llvm/llvm-project#69950 |
ardier
pushed a commit
to ardier/Halide-mutation
that referenced
this pull request
Mar 3, 2024
Explicitly mark which loops get loop-carry-dependencies inserted by sliding window to assist storage folding. Storage folding needs to know about this so it doesn't try to fold in a way that invalidates these read-after-write dependencies. It currently tries to prove the absence of hazards with box_contains(box_provided, box_required), but this is sometimes incorrect because box_provided could be conservatively large, and the code it analyses might not actually provide (store to) all the required (loaded from) values. It's simpler for sliding window to just tell storage folding when it inserts loop-carry-dependencies, and this is most simply done directly in the IR itself. Fixes halide#7909
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.
Explicitly mark which loops get loop-carry-dependencies inserted by
sliding window to assist storage folding.
Storage folding needs to know about this so it doesn't try to fold in a
way that invalidates these read-after-write dependencies. It currently
tries to prove the absence of hazards with box_contains(box_provided,
box_required), but this is sometimes incorrect because box_provided
could be conservatively large, and the code it analyses might not
actually provide (store to) all the required (loaded from) values.
It's simpler for sliding window to just tell storage folding when it
inserts loop-carry-dependencies, and this is most simply done directly
in the IR itself.
Fixes #7909
Built on #7908 to avoid a merge conflict in the fuzz_schedule.cpp test