To Agressive Simplify
- Dominant language
- Python
- Stars
- 593
- Forks
- 163
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 60
Description
The issue affects the following SDFG.
Which essentially performs (ignore the copy Map) the following operation:
```python
for i in range(N):
__out[i] = __in[i]
```
If we perform simplification then everything is correct.
But if we perform simplification, and running `TrivialTaskletElimination` transformation (which is correct) we get the following result:
Which locks correct until you start looking at the Memlet, you see that it is wrong.
As only one element is copied, because the iteration variable of the loop (which is empty and has not been eliminated) is used.
My guess is that something in redundant array elimination skews up.
I found this issue in GT4Py, but I have ensured that it is inside DaCe and not GT4Py.
## Reproducing
Pull `GT4Py` from my fork, `https://github.com/philip-paul-mueller/gt4py/` and check out branch `__dace_issue_2182`.
Then install it follow the instruction, but it essentially boils down to
```bash
uv sync --extra next --group dace-next
```
The offending test is location in:
```bash
pytest tests/next_tests/integration_tests/feature_tests/ffront_tests/test_execution.py::test_scalar_scan_vertical_offset[dace.run_dace_cpu]
```
Please be aware that GT4Py will cache the result of the lowering in `${PWD}/.gt4py_cache` thus if you made a modification and want to run it again, you have to remove the folder first.
For debugging purposes you can go into `${GT4PY_ROOT}/src/gt4py/next/program_processors/runners/dace/transformations/simplify.py`.
Contributor guide
Assessment
This issue has not been assessed yet.