ssm-lang / sslang

A language built atop the Sparse Synchronous Model
BSD 3-Clause "New" or "Revised" License
18 stars 0 forks source link

Parallel Expressions #33

Open j-hui opened 2 years ago

j-hui commented 2 years ago

"yield abstraction" might not be the best name for this, but that's what I've called it for now in our IR pipeline (and it does nothing right now). Perhaps "par lift" or "par abstraction" is a better term.

But @Rewbert actually brought up this issue as it was something he thought of while working on ssm-edsl.

Say we have something like this:

par do wait x
       after 1, y <- ()
    do after 1, x <- ()
       wait y

This expression alone already has some fairly interesting temporal behavior, and is something we do allow in our language. But codegen doesn't know how to deal with this, because it only knows how to deal with parallel function calls.

That can be achieved by lifting these into immediately applied lambdas:

par (\() -> wait x
            after 1, y <- ()) ()
    (\() -> wait y
            after 1, x <- ()) ()

This should be done before lambda lifting (#32) to ensure that these newly introduced lambdas are lifted to the top-level so that they are compatible with Codegen's compilation scheme.

j-hui commented 2 years ago

Oh and I should note that for parallel expression with no temporal behavior, they should just be desugared down into sequential code for efficiency (avoids unnecessary context switches). So for instance:

par x <- 1
    y <- 2

shoudl just desugar down into

let _ = x <- 1
y <- 2
sedwards-lab commented 2 years ago

It should be "parallel expressions"

Broadly, it's just desugaring par expr (|| expr)* into parallel function calls. We did something like this in the SHIM language; it's mechanical here because the expressions are totally ordered.