Add IR visitor to catch race conditions#121
Add IR visitor to catch race conditions#121jdahm wants to merge 15 commits intoGridTools:masterfrom jdahm:validation-pass
Conversation
gronerl
left a comment
gronerl
left a comment
There was a problem hiding this comment.
There are some more cases that could be caught that aren't right now, such as in runtime conditionals and for k-PARALLEL cases.
jdahm
changed the title
jdahm
changed the title
| InitInfoPass, | ||
| MergeBlocksPass, | ||
| NormalizeBlocksPass, | ||
| check_race_conditions, |
There was a problem hiding this comment.
This may be better put into an optimizations.py or ir_checkers.py ...
| return cls()(root_node) | ||
|
|
||
| def __init__(self): | ||
| self.iteration_order = None |
There was a problem hiding this comment.
Unused. Remove this before merging.
|
Hey, sorry i didn't reply sooner. According to the parallel model that we wrote down in the quickstart guide, this would actually not be the right behavior, namely the last test should exactly be valid. This sparked a discussion here about the parallel model which might change what is valid and what isn't. I assume and hope that networkx will not be necessary and that the tests can be done in the frontend. But this PR will remain pending until that is sorted out. |
|
Are you referring to
? |
|
@gronerl I thought about a frontend check at first, but the code cannot easily tell what will create a race condition until the stencil definition is lowered to implementation IR and stages/multistages are created. Actually technically we probably could, but I don't have a handle on what conditions (e.g. run-time conditionals) force certain statements to stay part of a stage. |
|
@eddie-c-davis and I worked on a version of this that works in the gtscript frontend, and raises an exception for the WAR issue: #143. I'll close this now in favor of that future PR. |
|
See #148. |
3 participants
Implements node visitors to detect race conditions.
Resolves #130 [DSL-91].
Co-authors: @eddie-c-davis