fix[next-dace]: detect write-after-read hazard in copy chain removal - #2863
Open
edopao wants to merge 1 commit into
Open
fix[next-dace]: detect write-after-read hazard in copy chain removal#2863edopao wants to merge 1 commit into
edopao wants to merge 1 commit into
Conversation
edopao
force-pushed
the
fix/copy-chain-remover-war
branch
from
September 4, 2026 14:02
1e3e29c to
eca19e5
Compare
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.
Description
CopyChainRemovermerges a(A1) -> (A2)copy by removing one container andrewiring the writes onto the survivor. In
PULLmode a transient double bufferA1is removed and its writes are taken over byA2, which moves those writesback to where
A1was produced.When the surviving container is a global that is also read elsewhere in the
same state, the removed transient was acting as a double buffer: it held the new
value while the old one was still being read. Merging it away leaves the write no
longer ordered after those reads, so the readers could observe the new value —
silently wrong results.
This is the pattern generated by an in-place update stencil, i.e. a field that a
field_operatorcall takes as an input and also produces as an output.Fix
Add
_creates_write_after_read_hazard: when the surviving container is anon-transient (global) that another AccessNode of the state still reads
(
out_degree != 0), reject the transformation. Transients are written only once(ADR-18), so they are unaffected and are skipped by the check.
Tests
test_copy_chain_destination_read_in_map_no_applyintest_copy_chain_remover.pyreproduces the in-place update pattern:
The
(b) -> (c)copy chain must not be removed, sincecsurvives and is stillread in the Map. The test compiles and runs the SDFG before and after, asserts the
transformation does not apply, and that the transient double buffer
bisretained. Verified that neutralizing the new guard makes the transformation apply,
confirming the test reproduces the issue.
Notes
This is one of a family of write-after-read fixes for in-place update stencils on
the DaCe backend (cf. #2815
GT4PyMapBufferElimination, #2816DoubleWriteRemover,#2817
GT4PyStateFusion). It targets a distinct transformation (CopyChainRemover)and does not overlap with those PRs; the reproducer deliberately mirrors the SDFG
shape used in #2816. The fix was extracted from the
dace_refactor_loweringdraft(#2690) into this standalone PR.