Suggest critical fixes for v1.0 (CLOSED)

[tbennun]

We are happy to announce the first release candidate of DaCe version 1.0!

This version uses the SDFG intermediate representation as published in the original Stateful Dataflow Multigraphs paper, which has been stable for quite some time.

On a fundamental level, this release is no different from a minor version release (this version could have been DaCe 0.17). However, with this release we would like to emphasize stability rather than new features.

If you are using DaCe and have a critical or blocking issue that makes it unstable, please create an issue and refer to it in the release discussion, so that we can add it to our release plan. Thank you for using DaCe!

Deadline is Monday, November 4. New contributions are now locked, thank you.

[philip-paul-mueller]

We should also add PR#1675, which addresses some bug that could affect code generation for CPU in some cases and generates also better code.
It was approved some time ago, but did not manged to go into the merge queue for some reason.

[phschaad]

Added to Milestone 1.0

[philip-paul-mueller]

We should also include PR#1708, which fixes bug that affects code generation.

[phschaad]

This is already in

[phschaad]

Not a PR that can be added to the milestone, but the release also depends on spcl/dace-vscode#268.

[ThrudPrimrose]

The to_gpu transformation puts all arrays to GPU, and then wraps all free tasklets (not within a scope) that write to a scalar to a GPU_Device map. But it does not wrap the tasklet if it only writes to an array. This results with an invalid SDFG.
My PR fixes it: #1713 , I would like it to be in 1.0.

[tbennun]

I don't think #1713 should be in 1.0. It changes the behavior of GPU transformations. Thus, it might break SDFGs that rely on this behavior in other projects that are not in the unit tests.

[ThrudPrimrose]

It only changes the behaviour if the a non-default value is passed to the added members. And therefore, it should not change existing behavior. However, this is mainly for ICON, and I do not think most of the programs need such specific control mechanisms. It makes sense not to include this in the focus on the other PRs for 1.0.

[FlorianDeconinck]

This might change stuff our side, if we decide to go in (sounds like not), ping me and I can ran tests within a couple weeks

[tbennun]

Looking at the PR, this is not guarded by any property, so it should in fact change the behavior. Let's just postpone this to after 1.0, this will not take long to merge in the less-stable main.

[ThrudPrimrose]

Looking at the PR, this is not guarded by any property, so it should in fact change the behavior. Let's just postpone this to after 1.0, this will not take long to merge in the less-stable main.

I mixed the comments for the other PR and this PR. Yes, this will change behavior. And yes, I agree.

[ThrudPrimrose]

#1701 Allows for better control of what gets offloaded to GPU in to_gpu transformation. I have improved it according to Alexnick's comment. I would like this to be a part of 1.0 too.

[tbennun]

This is likely good to include, I will need to review that again.

[ThrudPrimrose]

I ran the usual tests, but yes, this needs to be reviewed.

[alexnick83]

I tentatively have some important fixes and workarounds in the auto-opt-fixes branch. Specifically, the following may be interesting to pick (refer to main...auto-opt-fixes):

• There is a fix in newast.py concerning memlet propagation when symbols depend on other symbols. This could also be an API usage issue.
• There are some fixes regarding a known issue where SymPy considers two instances of a symbol to be different symbols. This is particularly nasty because it makes memlet propagation fail (no pattern matches, resulting in the default option, which frequently generates erroneous offset in nested SDFG accesses).
• Various transformation fixes, especially in fusion and remove-array transformations.
• There is a performance fix regarding copies of size 1. We currently use NDCopy regardless of the actual size, which results in abysmal performance in some compiler versions and machines when positioned inside an inner short loop.

Realistically, I do not think I will be able to make proper PRs before the end of the month. If the desired schedule is faster than that, you can ignore this.

[tbennun]

We should look into cherry picking from this. I also have things I would like to pull from https://github.com/spcl/dace/compare/main..various-fixes that improve the stability of simplify and interaction with compiled SDFGs Merged in #1724

[romanc]

I'd love to add #1727 to the list. As mentioned in the issue, there's some code in branch main...romanc:romanc/scalar-to-symbol that fixes my simple test cases.

[tbennun]

Thank you, this is important, added.

[tbennun]

Three additional comments I received:

• .dacecache generated code files end up with numeric suffixes in some cases
• SDFG._regenerate_code should be a public field
• SDFG.auto_optimize() should be a public method

#1738 / #1739 are added too

[tbennun]

#1740 and #1741