Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python frontend: Better support for scalar-ranges and dynamic ranges #650

Open
2 of 3 tasks
tbennun opened this issue Mar 17, 2021 · 1 comment
Open
2 of 3 tasks

Comments

@tbennun
Copy link
Collaborator

tbennun commented Mar 17, 2021

The Python frontend has trouble dealing with dynamic map inputs.

  • Some programs don't generate valid graphs:
@dace.program
def test(A: dace.float64[20], B: dace.float64[20]):
    N = dace.define_local_scalar(dace.int32)
    N = 5
    for i in dace.map[0:N]:
        for j in dace.map[0:N]:
            with dace.tasklet:
                a << A[i]
                b >> B[j]
                b = a + 1
  • others generate symbols instead of scalars:
@dace.program
def test(A: dace.float64[20], B: dace.float64[20], N: dace.int32):
    for i, j in dace.map[0:N, 0:N]:
            with dace.tasklet:
                a << A[i]
                b >> B[j]
                b = a + 1
  • and others generate code in the wrong order, allocating the scalars before setting their values:
@dace.program
def test(A: dace.float64[20], N: dace.int32):
    A[0:N] = 5
@alexnick83
Copy link
Contributor

It seems that we have competing designs for handling data-dependent symbols (I am not sure what would be a proper term):

  • There is the "dynamic map inputs" design, which is used to implement the original "dappy" SpMV. This is the design triggered in the second example, and the function handling this is actually promoting the scalar N to a symbol (not sure why tbh, as it is not necessary, probably a remnant of the next point).
  • There is an older design where scalars and symbols were going to be merged. Based on this, scalars are considered to be symbols and are used interchangeably. You can see this in the third example.
  • There is the newer design, where scalars are/must be explicitly be promoted to symbols, while the use of scalars must be considered "indirection." This has some interesting side effects. For example, the propagated memlets in the first example now have indirection. However, I cannot imagine what this SDFG would look like, and a call to add_memlet_path fails, so the SDFG is never generated to have a peak.

I think that the newer design ultimately makes more sense and is easier to generalize. We should consider re-designing dynamic map inputs and indirection based on the concept of scalar promotion. I will look into making a proposal to discuss.

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

No branches or pull requests

2 participants