-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor[next][dace]: cleanup dace backend module #1811
Conversation
…-gtir-refact-module
…-gtir-refact-module
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two things that must be taken care of:
- I thing that
debug_info()
was removed, but it seems to be still needed. - There is now a duplicated file in the
transformation
sub-package.
However, I do not think that these two warrant an extra round.
def debug_info( | ||
node: gtir.Node, *, default: Optional[dace.dtypes.DebugInfo] = None | ||
) -> Optional[dace.dtypes.DebugInfo]: | ||
"""Include the GT4Py node location as debug information in the corresponding SDFG nodes.""" | ||
location = node.location | ||
if location: | ||
return dace.dtypes.DebugInfo( | ||
start_line=location.line, | ||
start_column=location.column if location.column else 0, | ||
end_line=location.end_line if location.end_line else -1, | ||
end_column=location.end_column if location.end_column else 0, | ||
filename=location.filename, | ||
) | ||
return default | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can not find the new location of this function.
Also it is still referenced by other parts of the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, I silently moved it to gtir_sdfg_utils
so I could remove the dependency on gtir in the utils
module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay.
I just could not find it that was all.
But I noticed that for some reason Ctrl+F
is a bit unreliable, but I do not understand why.
But I very much like your reason.
Sorry for the false alarm.
@@ -0,0 +1,227 @@ | |||
# GT4Py - GridTools Framework |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The transformations
subpackage has now tow files with the exact same content, once utils.py
(which is new) and once util.py
(which was there before).
I actually do not care which one survives and in fact I would say that utils.py
should survive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. This must be an artifact of VSCode refactoring.
This PR fixes a bug in `DistributedBufferRelocator` that was observed in ICON4Py's `TestUpdateThetaAndExner` test. In essence there was an `assert` that assumed that checked if this temporary was a sink node, but, the code that finds all write backs was never excluding such cases, i.e. the temporaries that were selected might not be sink nodes in the state where they are defined. The `assert` was not part of the original implementation and is not a requirement of the transformation, instead it was introduced by [PR#1799](GridTools#1799), that fixed some issues in the analysis of read write dependencies. There are two solutions for this, either removing the `assert` or prune these kinds of temporaries. After some consideration, it was realized that handling such cases will not lead to invalid SDFG, as long as the other restrictions on the global data are respected. For that reason the `assert` was removed. However, we should thinking of doing something more intelligent in that case.
PR #1753 removed the
dace_iterator
backend, that before existed by side ofdace_fieldview
backend. Code common to these two backends was placed indace_common
module.The current GTIR-DaCe backend supports both iterator view and field view flavors of the GTIR, so there is no need for a distinction at the top level of the backend module.
This PR applies the following cleanup tasks:
The module
runners/dace/workflow
was also split into sub-modules. A doc string was added torunners/dace/workflow/__init__.py