Remove schedule property from NestedSDFG

[tbennun]

No description provided.

[BenWeber42]

What's the status here? I get the feeling this may no longer be current?

[tbennun]

@BenWeber42 It is a good idea and will simplify the SDFG representation. However, I do not have the bandwidth to correct all the involved issues. Perhaps this is better as kept in a project backlog of "things we want to modify in the SDFG representation" for a future version.

[BenWeber42]

Ok, thanks for the clarification. There's a small chance that I may be able to invest some time into this as part of a rework task (though, a bit unclear at the moment...).

I think it's easiest to keep the PR open for now.

[BenWeber42]

@tbennun I would like to continue working on this. Can I take over ownership of this branch?

[tbennun]

@BenWeber42 sounds good

[BenWeber42]

Around 100 testcases fail, because the schedule is set to "default" and the dispatcher (in code-gen) has nothing registered for "default". I believe the correct fix is to ensure no schedule is set to "default" before SDFG reaches the "dispatching mechanism" of code-gen (I am currently working on this).

However, this leads to the question: Is this a "correctness-condition" that no schedule can be "default" at the "dispatching mechanism"?
If so, we should probably add a check for this as a validation step before the "dispatching mechanism".

[tbennun]

Around 100 testcases fail, because the schedule is set to "default" and the dispatcher (in code-gen) has nothing registered for "default". I believe the correct fix is to ensure no schedule is set to "default" before SDFG reaches the "dispatching mechanism" of code-gen (I am currently working on this).

However, this leads to the question: Is this a "correctness-condition" that no schedule can be "default" at the "dispatching mechanism"? If so, we should probably add a check for this as a validation step before the "dispatching mechanism".

Looks like it is simply an issue of the storage/schedule type inference not setting all the storage types from default to what they should be. There should not be any Defaults once actual code generation starts; everything must be explicit. The type inference phase happens in the first phase of code generation, here: https://github.com/spcl/dace/blob/master/dace/codegen/codegen.py#L204

[BenWeber42]

Yes, last I was working on this PR, I was looking into this and debugging this function. I believe the function should be adjusted to accommodate the removal of the schedule property of nested SDFGs, but it wasn't clear to me yet how it should be adjusted. Unfortunately, I haven't been able to work on this PR for some time...