Skip to content

Conversation

creavin
Copy link
Collaborator

@creavin creavin commented Sep 14, 2025

This change adds a new DaCE Pass that can replace one simple DaCe dtype with another. This change was successfully tested on a complex ICON sdfg. Here is a sample usage:

import dace
import numpy as np

from dace.transformation import pass_pipeline as ppl
from dace.transformation.passes.type_change import TypeChange

N = dace.symbol('N')

@dace.program
def simple(a: dace.float64[N], b: dace.float64[1]):
    for i in range(N):
        a[i] = a[i] * 2.0 + b[0]

sdfg = simple.to_sdfg()
tc = TypeChange(dace.float64, dace.float32)

type_change_pipeline = ppl.Pipeline([tc])
print("Pipeline created")
results = type_change_pipeline.apply_pass(sdfg, {})

print(results) # {'TypeChange': 6}

A = np.ones(10, dtype=np.float32)
B = np.ones(1, dtype=np.float64)
sdfg(A, B, N=10)
print(A)

This change adds a new DaCE Pass that can replace one simple DaCe dtype
with another. This change was successfully tested on a complex ICON
sdfg. Here is a sample usage:

```
import dace
import numpy as np

from dace.transformation import pass_pipeline as ppl
from dace.transformation.passes.type_change import TypeChange

N = dace.symbol('N')

@dace.program
def simple(a: dace.float64[N], b: dace.float64[1]):
    for i in range(N):
        a[i] = a[i] * 2.0 + b[0]

sdfg = simple.to_sdfg()
tc = TypeChange(dace.float64, dace.float32)

type_change_pipeline = ppl.Pipeline([tc])
print("Pipeline created")
results = type_change_pipeline.apply_pass(sdfg, {})

print(results) # {'TypeChange': 6}

A = np.ones(10, dtype=np.float32)
B = np.ones(1, dtype=np.float64)
sdfg(A, B, N=10)
print(A)
```
@creavin creavin requested a review from acalotoiu September 14, 2025 20:34
@tbennun
Copy link
Collaborator

tbennun commented Sep 15, 2025

I’m not sure this is a good candidate for a pass. Maybe if it checked for reductions and, e.g., transcendental ops, for higher precision it would be more appropriate. Otherwise, as it is right now it should be a utility function.

Additionally, please avoid type(x) == y checks

Copy link
Collaborator

@phschaad phschaad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments for code improvements. Additionally, I agree with the point raised by @tbennun

@creavin
Copy link
Collaborator Author

creavin commented Sep 15, 2025

Thank you both for your comments

I’m not sure this is a good candidate for a pass. Maybe if it checked for reductions and, e.g., transcendental ops, for higher precision it would be more appropriate. Otherwise, as it is right now it should be a utility function.

I'm happy to move this into a utility function then. Where is the correct place to put it / do you have a similar function I can mimic

Additionally, please avoid type(x) == y checks

Yes, good point. Will use isinstance instead

This change adds a new DaCE Pass that can replace one simple DaCe dtype
with another. This change was successfully tested on a complex ICON
sdfg. Here is a sample usage:

```
import dace
import numpy as np

from dace.transformation.helpers import replace_sdfg_dtypes

N = dace.symbol('N')

@dace.program
def simple(a: dace.float64[N], b: dace.float64[1]):
    for i in range(N):
        a[i] = a[i] * 2.0 + b[0]

sdfg = simple.to_sdfg()
results = replace_sdfg_dtypes(sdfg, dace.float64, dace.float32)

print(results) # {'TypeChange': 6}

A = np.ones(10, dtype=np.float32)
B = np.ones(1, dtype=np.float64)
sdfg(A, B, N=10)
print(A)
```
@creavin
Copy link
Collaborator Author

creavin commented Sep 20, 2025

Changes:

  • moved to helper function file
  • uses isinstance checks
  • ran linter first
  • I keep literal == checks for the direct because I know that behaviour to work correctly. I don't have the time to extensively test for new behaviour with isinstance

@creavin creavin requested a review from phschaad September 21, 2025 10:23
Copy link
Collaborator

@phschaad phschaad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change looks good to me, however the PR is missing unit tests. This is a new feature and as such is certainly not covered by existing tests. Please ensure there are at least 2-3 unit tests to check for correct type changing behavior w.r.t. the data types and places the utility function modifies.

@creavin
Copy link
Collaborator Author

creavin commented Sep 22, 2025

Perfect, will do

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants