You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hunting for a bad write in our model we discovered that DaCe had swapped two maps order with no data dependency. This was tracked down to FuseStates misbehaving. While reproducing, the error was fickle, disappearing easily - we rebuild a partial reproducer showing the bug and showing a determinism issue with the pass.
Fuse States issue
The original SDFG looks like this (file attached below)
Block_3 has q has an input Block_5 has q has an output
Block 3 and 5 are effectively not sharing data dependency (output of 3 is not used in 5) but the order of blocks matter since this is a write-after-read situation.
When FuseStates applied (see beloew) FuseStates produces a single Block:
First quick look shows that this code in StateFusion.can_be_applied
# If we have potential candidates, check if there is a# path from the first write to the second write (in that# case, there is no hazard):forcandinwrite_write_candidates:
nodes_first= [nforninfirst_outputifn.data==cand]
nodes_second= [nforninsecond_outputifn.data==cand]
# If there is a path for the candidate that goes through# the match nodes in both states, there is no conflictifnotself._check_paths(
first_state,
second_state,
match_nodes,
nodes_first,
nodes_second,
second_input,
False,
False,
):
returnFalse# End of write-write hazard check
Is (sometimes) not triggered leading to the bad merge
Hunting for a bad write in our model we discovered that DaCe had swapped two maps order with no data dependency. This was tracked down to
FuseStates
misbehaving. While reproducing, the error was fickle, disappearing easily - we rebuild a partial reproducer showing the bug and showing a determinism issue with the pass.Fuse States issue
The original SDFG looks like this (file attached below)
Block_3
hasq
has an inputBlock_5
hasq
has an outputBlock 3 and 5 are effectively not sharing data dependency (output of 3 is not used in 5) but the order of blocks matter since this is a write-after-read situation.
When
FuseStates
applied (see beloew)FuseStates
produces a single Block:instead of two:
Lack of determinism
Using the attached unsimplified.sdfg.txt as the input
This simple script should reproduce the above
Will print 7 if the error shows BUT could be printing 6 if the error magically doesn't show.
Wrapping into a simple bash should show the issue
The text was updated successfully, but these errors were encountered: