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

WindowStmt(s) aren't treated as declarative statements within the compiler #594

Open
SamirDroubi opened this issue Mar 15, 2024 · 0 comments
Labels
S: Needs Discussion This needs discussion to decide if important to work T: Bug Something isn't working

Comments

@SamirDroubi
Copy link
Collaborator

Must of our rewrites pay attention to liveness issue of variables declared by alloc statements. However, we don't ensure similar checks for WindowStmts. This means that a schedule like the following:

def test_fission_after_window_stmt(golden):
    @proc
    def foo(n: size, res: f32, x: f32[1]):
        for i in seq(0, n):
            win = x[0:1]
            res += win[0]

    foo = fission(foo, foo.find("win = _").after())

Can result in the following:

def foo(n: size, res: f32 @ DRAM, x: f32[1] @ DRAM):
    for i in seq(0, n):
        win = x[0:1]
    for i in seq(0, n):
        res += win[0]

which is incorrect because win is not live at the read.

There are multiple solutions to this:

  • Go and make sure that we also consider WindowStmt anywhere we do something special for an Alloc.
  • Expand the semantics of Alloc to be a decelerative statements for allocations and Windows: win: [f32][1]; win = x[0:1]
  • Reassess how important it is to have a WindowStmt. My impression is that this is not something that you naturally use, it often results from inlining procedure which we often follow by inlining the windows manually, but you could also imagine inlining the windows as well by default. I guess I don't think I have seen an example where the existence of a WindowStmt has been valuable and I wonder if it makes sense to remove it for the sake of simplifying the IR and reducing the number of statements you have to worry about when writing user-code.
@SamirDroubi SamirDroubi added T: Bug Something isn't working S: Needs Discussion This needs discussion to decide if important to work labels Mar 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S: Needs Discussion This needs discussion to decide if important to work T: Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant