fix[next][dace]: Fix array subset on the branches of if-expressions #1912
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
edopao
changed the title
edopao
commented
Mar 19, 2025
| else: | ||
| # TODO(edopao): this is a workaround for some IR nodes where the inferred | ||
| # domain on a tuple of fields is not a tuple, see `test_execution.py::test_ternary_operator_tuple()` | ||
| domain_tree = gtx_utils.tree_map(lambda _: node.annex.domain)(symbol_tree) |
There was a problem hiding this comment.
@tehrengruber I am using a workaround because domain inference does not create a tuple, as expected, in test_execution.py::test_ternary_operator_tuple()
There was a problem hiding this comment.
As agreed, I am going to use an API to correctly retrieve the annex domain when it is available.
.../next_tests/unit_tests/program_processor_tests/runners_tests/dace_tests/test_gtir_to_sdfg.py
Outdated
Show resolved
Hide resolved
.../next_tests/unit_tests/program_processor_tests/runners_tests/dace_tests/test_gtir_to_sdfg.py
Outdated
Show resolved
Hide resolved
.../next_tests/unit_tests/program_processor_tests/runners_tests/dace_tests/test_gtir_to_sdfg.py
Outdated
Show resolved
Hide resolved
.../next_tests/unit_tests/program_processor_tests/runners_tests/dace_tests/test_gtir_to_sdfg.py
Outdated
Show resolved
Hide resolved
src/gt4py/next/program_processors/runners/dace/gtir_builtin_translators.py
Outdated
Show resolved
Hide resolved
src/gt4py/next/program_processors/runners/dace/gtir_builtin_translators.py
Outdated
Show resolved
Hide resolved
src/gt4py/next/program_processors/runners/dace/gtir_builtin_translators.py
Show resolved
Hide resolved
src/gt4py/next/program_processors/runners/dace/gtir_builtin_translators.py
Outdated
Show resolved
Hide resolved
src/gt4py/next/program_processors/runners/dace/gtir_builtin_translators.py
Show resolved
Hide resolved
edopao
force-pushed
the
gtir-dace-array_memlet
branch
from
dbe2ffc to
bf48f00
Compare
philip-paul-mueller
approved these changes
Mar 21, 2025
Thanks for the review. I have already discussed the domain inference problems with Till, there will be some utility functions to get the tuple domain (and the domain range in general, which might be useful in multiple places of the SDFG lowering). |
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.
The issue was discovered by Philip (@philip-paul-mueller).
The lowering of if-expressions has to ensure that all branches (e.g. if/then states) write the same subset to the result array. This was not the case in baseline when one the branches contained a simple expression such as
{dwdx, dwdy}. The bug was that the full shape of the global fields was copied into the result array, although the result array was allocated on a sub-domain. This caused an out-of-bound write and a segfault.