DeadDataflowElimination fails to "inline" non-scalarized outputs

[romanc]

Describe the bug

DeadDataflowElimination removes transient write access nodes that aren't read anymore. If the source is a Tasklet, that Tasklet needs to be changed. The write can be "inlined", i.e. scoped to the Tasklet (since it's never read after the Tasklet).

This "linining" or localization of the write fails for non-scalized memlets, as in the attached SDFG where the Tasklet writes into a 2x2 array. The issue presents itself as simplify() / DDE complaining that 'pointer' objects have no attribute 'typename'.

To Reproduce

Steps to reproduce the behavior:

1. Load this sdfg: dde-pointer-inline.sdfg.zip
2. Run simplify() on the loaded sdfg.
3. See error

Expected behavior

I'd expect DDE to either correctly scope the write to the Tasklet or not attempt to remove the write access node.

Screenshots

OS / version info

• OS: Linux
• DaCe version: present in both, main (as of 25-07-16) and the v1/maintenance branch
• Python version: 3.11.9

Additional context

>>> SDFG.from_file("./dde-pointer-inline.sdfg")
SDFG (TestTypedTemporary_dacecpu_3)
>>> sdfg = SDFG.from_file("./dde-pointer-inline.sdfg")
>>> sdfg.validate()
>>> sdfg.simplify()
Traceback (most recent call last):
  File "[...]/dace/dace/transformation/passes/dead_dataflow_elimination.py", line 164, in apply
    ast_find.generic_visit(code)
  File "[...]/python/3.11.9/lib/python3.11/ast.py", line 494, in generic_visit
    value = self.visit(value)
            ^^^^^^^^^^^^^^^^^
  File "[...]/python/3.11.9/lib/python3.11/ast.py", line 418, in visit
    return visitor(node)
           ^^^^^^^^^^^^^
  File "[...]/python/3.11.9/lib/python3.11/ast.py", line 503, in generic_visit
    new_node = self.visit(old_value)
               ^^^^^^^^^^^^^^^^^^^^^
  File "[...]/python/3.11.9/lib/python3.11/ast.py", line 418, in visit
    return visitor(node)
           ^^^^^^^^^^^^^
  File "[...]/dace/dace/frontend/python/astutils.py", line 588, in visit_Name
    raise NameFound(node.id)
dace.frontend.python.astutils.NameFound: gtOUT__tmp

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "[...]/dace/dace/sdfg/sdfg.py", line 2567, in simplify
    pass_options=options).apply_pass(self, {})
                          ^^^^^^^^^^^^^^^^^^^^
  File "[...]/dace/dace/transformation/passes/simplify.py", line 158, in apply_pass
    result = super().apply_pass(sdfg, pipeline_results)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[...]/dace/dace/transformation/pass_pipeline.py", line 614, in apply_pass
    newret = super().apply_pass(sdfg, state)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[...]/dace/dace/transformation/pass_pipeline.py", line 574, in apply_pass
    r = self.apply_subpass(sdfg, p, state)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[...]/dace/transformation/passes/simplify.py", line 128, in apply_subpass
    subret = p.apply_pass(sd, state)
             ^^^^^^^^^^^^^^^^^^^^^^^
  File "[...]/dace/transformation/pass_pipeline.py", line 309, in apply_pass
    retval = self.apply(region, pipeline_results)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[...]/dace/transformation/passes/dead_dataflow_elimination.py", line 168, in apply
    f'{leaf.src_conn}: dace.{ctype.to_string()}\n'
                             ^^^^^^^^^^^^^^^^^
  File "[...]/dace/dace/dtypes.py", line 441, in to_string
    return self.typename or self.type.__name__
           ^^^^^^^^^^^^^
AttributeError: 'pointer' object has no attribute 'typename'

[FlorianDeconinck]

@phschaad would you mind having a first look at this? We though we got a temporary workaround but it has nasty side effect. Looking for guidance.

[phschaad]

I am working on a fix for this (tracking #2098, and #2099 for the backport to v1/maintenance).
The issue is that DDE should not apply on tasklets of this form to begin with, since the application (or rather, the mentioned "inlining") would require a relatively complex dataflow analysis inside of a tasklet - which goes against the DaCe philosophy of being able to treat tasklets as black boxes*. DDE seems to currently happily attempt to apply in these situations, though, and I have thus implemented a fix to check for and skip this scenario.

If elimination is required in a case like this, the tasklet should:
a) either be finer grained (split over multiple tasklets)
b) or have multiple (in this case 4) separate scalar output connectors that collectively end in the corresponding array access node, as opposed to bundling the index accesses into the tasklet.

* as much as possible...

[romanc]

Thanks, Phil. I agree, the simplest is for DDE to just not apply in these situations. Your fix is very much along the lines of what we have put in as a stop-gap solution in our working branch.

We have currently no requirement for elimination in case of Tasklets of this form. The discussion in #2098 is interesting from an ideological point of view and I have a follow-up question regarding the Tasklet validity discussion. In this situation, all four accesses to tmp are static and known when we create the SDFG. We could thus change the Tasklet as suggested. In other cases, we have dynamic accesses and it is impractical / impossible to scalarize all the inputs/outputs. Is that a problem (in the future)? In my opinion, it's fine if we get to points like this where passes perform sub-optimally. I just want to make sure that this discussion doesn't trigger a reaction of "let's forbid pointer / size > 1 tasklet data".

[phschaad]

Those kinds of inputs are not a problem - or at least they should never be. They are also key for indirect accesses and thus sparse computations. They should always be treated correctly by DaCe (which is why this is still certainly a bug in my eyes and warrants the fix). My point in #2098's discussion is more to indicate that no analysis should be expected to make an effort to treat those kinds of accesses in anything other than a conservative "do not touch too much" manner. It should thus probably not be that this would ever be "forbidden", as much as "discouraged" with a clear indication that it hinders optimization.