Lower functions to FuTIL's `invoke`. #340

cgyurgyik · 2020-12-28T14:31:05Z

So I've spent some time going over the FuTIL backend for Dahlia, as well as Scala. There's still a few things I'm unsure about. I'll try to lay out my thoughts below, and hopefully receive some guidance.

So within the invoke, we need to connect Ports and PortDefs, e.g. param = x.out. I've created a new class InvokeConnect for this, since Connect is only for Ports. I'm not entirely sure what the comparisons are for either.
I've then created an Invoke class, which takes in a CompVar and a List[InvokeConnect].

However, this still doesn't do two things. First, give us the input parameters to a function. For example,

def foo (x: ubit<32>){ ... }

We need a list of the input parameters, which in this case would simply be List(PortDef(CompVar("x"), 32)).
We also need to create a separate component for the body of foo (or import it if foo is imported).

I've created a toy program with void output since I'm unsure of the syntax for returning anything other than void:

def timestwo (x: ubit<32>[1]){ x[0] := 1; }

decl A: ubit<32>[1];
let _x = timestwo(A);

This lowers to:

import "primitives/std.lib";
component main() -> () {
  cells {
    A = prim std_mem_d1_ext(32,1,1);
    _x0 = prim std_reg(0);
    timestwo0 = timestwo;
  }
  wires {
    group let0 {
      _x0.in = timestwo0.out;
      _x0.write_en = timestwo0.done;
      let0[done] = _x0.done;
    }
    invoke timestwo0(input = A.out)() // Here, `input` is hardcoded.
    // ^ Unsure why this is after the group. I presume it should in the control.
  }
  control {
    let0;
  }
}

Thanks for the help :)

rachitnigam · 2020-12-28T22:52:45Z

So, I think there is a top-level confusion about invoke and FuTIL-defined components here:

Components defined by FuTIL (currently) do not support parameters. This means when you see something like:

def bar(x: ubit<32>) { ... }
bar(y)

it should become:

component bar(x: 32) -> (ret: 32) { ... }
component main() {
  cells { 
    b = bar; // <- Takes no PortDefs
    y = std_reg(32);
  }
  wires { ... }
  control {
    invoke bar(x = y.out)();
  }
}

Few code related things that are tripping you up:

Invoke should be a Control, not a Structure.
invoke does not need anything in wire, it just takes port connections.

Let me know if that makes sense. FuTIL has an invoke test in test/correctness/invoke.futil.

cgyurgyik · 2020-12-29T02:16:08Z

In your example:
I meant

component bar(x: 32) -> (ret: 32) { ... }
component main() {
  cells { 
    b = bar; 
    y = std_reg(32);
  }
  wires { ... }
  control {
    invoke bar0(x = y.out)(); // <- `src` = PortDef, `dest` = Port
  }
}

This is why I created an InvokeConnection, which allowed for this (more below).

The bit about it being a Control is helpful!
Following your initial steps, I now have:

def two(x: ubit<32>){ x := 2; }
let y: ubit<32> = (1 as ubit<32>);
---
two(y);

Lowered to:

import "primitives/std.lib";
component main() -> () {
  cells {
    const0 = prim std_const(32,1);
    y0 = prim std_reg(32);
    two0 = two;
  }
  wires {
    group let0<"static"=1> {
      y0.in = const0.out;
      y0.write_en = 1'd1;
      let0[done] = y0.done;
    }
  }
  control {
    seq {
      let0;
      invoke two0(y0.out)() 
    }
  }
}

In the following line:

invoke two0(y0.out)() // <- Just passing in the output ports, but we want `x = y0.out`

I'm just passing in the emitted ports from the inputs to the EApp, but what we really want is x = y0.out. I created an InvokeConnection for this (Port, PortDef) representation, but perhaps that's wrong. The second issue is, how to access the parameter names of the component, in this case, x? Presumably from the component that is emitted?

rachitnigam · 2020-12-29T02:36:41Z

You will have to walk over the definitions in the program and build a mapping from name to the signature. The Prog structure has defs which is not correctly handled by the FuTIL backend:
https://github.com/cucapra/dahlia/blob/master/src/main/scala/backends/futil/FutilBackend.scala#L766

rachitnigam · 2020-12-29T20:12:47Z

We should probably remove the magic compilation for sqrt, exp, etc: https://github.com/cucapra/dahlia/pull/340/files#diff-85f1b567d1bc7b96825cab43f656b8e562a1561c8a0cc1fbf25765e9b6f586d3R559

rachitnigam · 2020-12-29T20:27:50Z

We should attempt to fix #333 while we're at this.

cgyurgyik · 2020-12-30T23:54:40Z

Please forgive the Scala lack-of-knowledge hackups. Here's current progress:

def two(x: ubit<32>){ }
let y: ubit<32> = (1 as ubit<32>);
---
two(y);

=>

import "primitives/std.lib";
component main() -> () {
  cells {
    const0 = prim std_const(32,1);
    y0 = prim std_reg(32);
    two0 = two;
  }
  wires {
    group let0<"static"=1> {
      y0.in = const0.out;
      y0.write_en = 1'd1;
      let0[done] = y0.done;
    }
  }
  control {
    seq {
      let0;
      invoke two0(x=y0.out)()
    }
  }
}
component two() -> () {
  cells {
  }
  wires {
  }
  control {
    empty
  }
}

Question: How does one write a return type in Dahlia?
For example, def two(x: ubit<32>) -> ubit<32> { ... } // return type is ubit<32>

rachitnigam · 2020-12-31T00:04:38Z

This is looking good! Dahlia return types are written as:

def foo(x: ubit<32>): ubit<32> { }

There is going to be some impedance mismatch between invoke-able components and values returned by Dahlia. There is no way to simultaneously invoke something and save the value generated on the output port.

To "return" values, invoke states that certain output ports should keep outputting values after the invoke statement is done executing. This way, you can save the value in a group that executes after the invoke. The invoke test in the FuTIL repo uses this to save the value generated through an invoke.

cgyurgyik · 2020-12-31T02:26:31Z

This is looking good! Dahlia return types are written as:
def foo(x: ubit<32>): ubit<32> { }
There is going to be some impedance mismatch between invoke-able components and values returned by Dahlia. There is no way to simultaneously invoke something and save the value generated on the output port.

To "return" values, invoke states that certain output ports should keep outputting values after the invoke statement is done executing. This way, you can save the value in a group that executes after the invoke. The invoke test in the FuTIL repo uses this to save the value generated through an invoke.

Ok noted. I've added signatures for the invoked components.

case EApp(id, inputs@_) => {
        val function_name = id.toString()
        val decl = CompDecl(genName(function_name), CompVar(function_name))
        // TODO: How to add `invoke` to control {} ?
        EmitOutput(decl.id.port("out"), decl.id.port("done"), List(decl), None)
      }

So the above case is hit when I have an expression such as let y: ubit<32> = foo(x);.
How would I emit the invoke code that is part of the control, usually done in emitCmd? Perhaps I'm missing something simple here.

rachitnigam · 2020-12-31T04:24:40Z

Hm, this is going to require some deeper thinking. I think we'll have to make some assumptions. For example, we can say that EApp is only supported when it's inside a let expression by explicitly matching on:

case CLet(name, typ, EApp(...)) => ...

And throw an error if we encounter EApp anywhere else. This is also how we handle memory reads which need to be "hoisted" before hand in a different pass (it's called HoistMemoryReads). We can implement a similar pass for applications.

Extra compilers sermon: In general, when building compiler backends, we can make these sorts of assumptions and then write "lowering" passes that bring programs in a desired format. A good way to visualize compilers is a funnel: as we continue compiling programs, they become restricted to smaller and smaller languages and have stronger and stronger assumptions.

cgyurgyik · 2020-12-31T20:17:05Z

Hm, this is going to require some deeper thinking. I think we'll have to make some assumptions. For example, we can say that EApp is only supported when it's inside a let expression by explicitly matching on:
case CLet(name, typ, EApp(...)) => ...
And throw an error if we encounter EApp anywhere else. This is also how we handle memory reads which need to be "hoisted" before hand in a different pass (it's called HoistMemoryReads). We can implement a similar pass for applications.

Extra compilers sermon: In general, when building compiler backends, we can make these sorts of assumptions and then write "lowering" passes that bring programs in a desired format. A good way to visualize compilers is a funnel: as we continue compiling programs, they become restricted to smaller and smaller languages and have stronger and stronger assumptions.

Great thanks Rachit! Compiler sermons are welcome here.

cgyurgyik · 2020-12-31T20:24:42Z

Progress:

def two(a: ubit<32>, b: ubit<32>): ubit<32> {
  let R: ubit<32> = (2 as ubit<32>);
  return R;
}

let y: ubit<32> = (1 as ubit<32>);
---
let z: ubit<32> = two(y, y);

=>

import "primitives/std.lib";
component two(a: 32, b: 32) -> (out: 32) {
  cells {
    R0 = prim std_reg(32);
    const1 = prim std_const(32,2);
  }
  wires {
    group let2<"static"=1> {
      R0.in = const1.out;
      R0.write_en = 1'd1;
      let2[done] = R0.done;
    }
    out = R0.out;
  }
  control {
    let2;
  }
}
component main() -> () {
  cells {
    const0 = prim std_const(32,1);
    y0 = prim std_reg(32);
    z0 = prim std_reg(32);
    two0 = two;
  }
  wires {
    group let0<"static"=1> {
      y0.in = const0.out;
      y0.write_en = 1'd1;
      let0[done] = y0.done;
    }
    group let1 {
      z0.in = two0.out;
      z0.write_en = 1'd1;
      let1[done] = z0.done;
    }
  }
  control {
    seq {
      let0;
      invoke two0(a=y0.out, b=y0.out)();
      let1;
    }
  }
}

There's one TODO that needs some more thinking.

          // TODO(cgyurgyik):
          // Currently, we store the parameters in functionStore as CompVars.
          // However, when reading their values, we are using an out port, which shouldn't be necessary.
          // e.g.,
          //
          // foo(x: 32) -> () {
          //   someRegister.in = x.out // We simply want `x` here.
          // }

Perhaps we should have another store for component port definitions?

sampsyo · 2020-12-31T21:45:50Z

Super cool. Just wanted to endorse @rachitnigam's idea here:

This is also how we handle memory reads which need to be "hoisted" before hand in a different pass (it's called HoistMemoryReads). We can implement a similar pass for applications.

Indeed, since we already have in-Dahlia pass infrastructure to hoist these things into something approximating A-normal form, it makes sense to do it again for invocations. This frees us from needing to invent names for the intermediate state when generating the FuTIL. 👍

rachitnigam · 2020-12-31T22:19:48Z

There's one TODO that needs some more thinking.

Can you provide some context about this? I don't remember the details of functionStore etc.

src/main/scala/backends/futil/FutilBackend.scala

rachitnigam · 2020-12-31T23:56:49Z

Ah, I see. The problem is that function arguments are treated as just another let bound variable and the compiler tries to hook up their .out ports.

One possible trick is to make the Store data structure more generic:

case class Store(localVars: Map[CompVar, CompVar], args: Map[CompVar, CompVar])

and change the EVar handling code.

An alternative design could be changing Store to carry this information for each binding:

sealed trait VType
case object LocalVar extends VType
case object Arg extends VType

type Store = Map[CompVar, (CompVar, VType)]

One thing to do regardless is to make Store a case class and define interface methods on it like .get so changes like these are easier to make in the future.

I misunderstood your question initially so I wrote a long explanation of how invoke's interface is supposed to work. Leaving it here to reinforce our understanding:

Let me clarify: There is no way to "return" values from an invoke. Here is how the invoke interface is supposed to be called.

Define a component with at least one port that outputs values after the invoke statement is done executing. This is done by having a "continuous assignment" to an output port of a component. Let's call such output ports "stable"

component bar(in: 32) -> (out: 32) {
  cells { x = prim std_reg(32); }
  wires { 
    group incr_x { /* do something to x */ }
    // This is outside a group which means it will stay activate 
    // even after the `go` signal to bar is low.
    out = x.out;
  }
  control { incr_x; }
}

In the control program, invoke the cell and after the invoke, use the values from one of the "stable" output ports

component main() -> () {
  cells { b = bar; }
  wires {
    group use_out {
       // use the output from b.out **after** invoking the component
       k.in = b.out;
    }
  }
  control {
    // Invoke the statement for stateful update
    invoke(in = y.out)(/* no assignment to out yet */);
    // Use the stateful update
    use_out;
  }

cgyurgyik · 2021-01-01T00:02:02Z

Ok great, that's what I'm doing. I initially was using an object that extends an Enumeration; I'll look into sealed traits after I get that functioning.

I think the example of progress I provided above is aligned with what you're saying above. My logic says that if the return value is non-void, add an out port to the component signature with the corresponding bit width.

rachitnigam · 2021-01-01T00:15:21Z

Oh interesting! I didn't know about Enumeration. Scala 2 (current version of Scala), annoyingly, does not have proper Enumerations with pattern match exhaustive checking. Instead people use the sealed trait, case object pattern to implement enumerations.

The soon-to-be-released Scala 3 has proper enumerations.

rachitnigam · 2021-01-03T16:07:38Z

We need to do a few things before merging:

Test that none of the benchmarks break when we do this. They will probably break because we haven't come up with a linking scheme for dahlia's import statements (what does import "math.h" in Dahlia turn into).
Add a correctness test in the FuTIL repository to make sure function compilation is working. (futil #346)
Emit reasonable error message when one of the arguments is a memory (probably just a NotYetImplemented error like in other places). ed2a006

cgyurgyik · 2021-01-06T23:27:32Z

def bar(A: ubit<32>[1]): ubit<32> = { }

Corresponding error:

[Error] [Line 1, Column 9] Memory as a parameter is not supported yet.
def bar(A: ubit<32>[1]): ubit<32> = { }
        ^
 This feature is not yet implemented. Please open a feature request for it.

cgyurgyik · 2021-01-06T23:46:08Z

For import, I presume this is the same thing as what is discussed by Adrian in Futil #299?

If I'm understanding @sampsyo correctly, math.h would contain Futil components rather than Dahlia functions.

A naive approach would just be the preprocessor way of copy-and-paste into the outputted Futil. However, we'd have to take into account the different types.

For example, if math.h supports some arbitrary component mathOp(x), how do we (cleanly) generalize it to support any input and type?

e.g.

import "math.h"
let a: ubit<32> = mathOp((42 as ubit<32>));
let b: ubit<8> = mathOp((42 as ubit<8>));
// Two different `mathOp` Futil components needed here.

sampsyo · 2021-01-07T01:10:32Z

While this statement obviously requires further discussion, what we want is parametric polymorphism.

rachitnigam · 2021-01-27T19:11:48Z

@cgyurgyik once #346 is implemented, can you add support for generating import statements in the Futil backend?

cgyurgyik · 2021-01-27T21:05:33Z

@cgyurgyik once #346 is implemented, can you add support for generating import statements in the Futil backend?

Sure thing.

cgyurgyik · 2021-01-28T23:26:05Z

Supports Futil imports, making two assumptions:

The imported function is always invokeable. (Currently not the case; blocked on Futil #331)
It is always prefixed with the prim keyword, i.e. it is a LibDecl. The end goal is to unify primitives and components, so blockled on Futil #372.

rachitnigam · 2021-01-30T16:26:33Z

Fixes #339.

cgyurgyik added 2 commits December 28, 2020 09:11

Initial commit.

a7769ed

Remove comment.

9c54b88

cgyurgyik requested a review from rachitnigam December 28, 2020 14:31

cgyurgyik linked an issue Dec 28, 2020 that may be closed by this pull request

Add FuTIL lowering for invoke. #339

Closed

Use control!

9a3ba87

Progress

b22bad1

Add signatures for invoked components.

2c50f04

cgyurgyik added 2 commits December 30, 2020 21:29

Add TODOs to remove sqrt, exp.

f4cd30a

Capital F.

44083d3

cgyurgyik added 2 commits December 31, 2020 15:17

Compile both void and returns.

23bb273

Add TODO for functionStore.

f8b5cf6

cgyurgyik commented Dec 31, 2020

View reviewed changes

src/main/scala/backends/futil/FutilBackend.scala Outdated Show resolved Hide resolved

cgyurgyik added 2 commits December 31, 2020 19:17

Working version with Enumeration. Next: Change to sealed trait.

6b74115

Use sealed trait.

3b1aca3

cgyurgyik added 2 commits January 1, 2021 09:52

Add underscore.

6795524

Add eg

36bf005

cgyurgyik changed the title ~~(WIP) Lower functions to FuTIL's invoke.~~ Lower functions to FuTIL's invoke. Jan 1, 2021

cgyurgyik mentioned this pull request Jan 6, 2021

Dahlia frontend invoke test. calyxir/calyx#346

Merged

Add error message for memory params

ed2a006

cgyurgyik mentioned this pull request Jan 26, 2021

[Relay] Toward a working VGG Net (continued). calyxir/calyx#369

Closed

8 tasks

cgyurgyik and others added 4 commits January 28, 2021 15:31

Merge branch 'master' into invoke

3213bd1

External.

bc09799

Imports part 1

c1ebb37

Add import.

3675547

cgyurgyik and others added 9 commits January 28, 2021 18:29

Update expected.

f88908f

scala fmt

dd0f45d

unnecessary check

f0262ed

group that reads from invoke runs in sequence

8eb3ff6

return is a vim keyword

b97528f

dont reimplement the same function;

aebeec1

construct structure generated from arguments to functions

12df06b

Merge branch 'master' into invoke

2836e0b

unify LibDecl and CompDecl into Cell

8b242fb

update polybench to use invokeable sqrt

55a94f2

rachitnigam merged commit 9a2ad3e into master Jan 30, 2021

rachitnigam deleted the invoke branch January 30, 2021 16:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Lower functions to FuTIL's `invoke`. #340

Lower functions to FuTIL's `invoke`. #340

cgyurgyik commented Dec 28, 2020

rachitnigam commented Dec 28, 2020

cgyurgyik commented Dec 29, 2020 •

edited

Loading

rachitnigam commented Dec 29, 2020

rachitnigam commented Dec 29, 2020

rachitnigam commented Dec 29, 2020

cgyurgyik commented Dec 30, 2020 •

edited

Loading

rachitnigam commented Dec 31, 2020

cgyurgyik commented Dec 31, 2020

rachitnigam commented Dec 31, 2020

cgyurgyik commented Dec 31, 2020

cgyurgyik commented Dec 31, 2020

sampsyo commented Dec 31, 2020

rachitnigam commented Dec 31, 2020

rachitnigam commented Dec 31, 2020

cgyurgyik commented Jan 1, 2021 •

edited

Loading

rachitnigam commented Jan 1, 2021 •

edited

Loading

rachitnigam commented Jan 3, 2021 •

edited by cgyurgyik

Loading

cgyurgyik commented Jan 6, 2021

cgyurgyik commented Jan 6, 2021 •

edited

Loading

sampsyo commented Jan 7, 2021

rachitnigam commented Jan 27, 2021

cgyurgyik commented Jan 27, 2021

cgyurgyik commented Jan 28, 2021 •

edited

Loading

rachitnigam commented Jan 30, 2021

Lower functions to FuTIL's invoke. #340

Lower functions to FuTIL's invoke. #340

Conversation

cgyurgyik commented Dec 28, 2020

rachitnigam commented Dec 28, 2020

cgyurgyik commented Dec 29, 2020 • edited Loading

rachitnigam commented Dec 29, 2020

rachitnigam commented Dec 29, 2020

rachitnigam commented Dec 29, 2020

cgyurgyik commented Dec 30, 2020 • edited Loading

rachitnigam commented Dec 31, 2020

cgyurgyik commented Dec 31, 2020

rachitnigam commented Dec 31, 2020

cgyurgyik commented Dec 31, 2020

cgyurgyik commented Dec 31, 2020

sampsyo commented Dec 31, 2020

rachitnigam commented Dec 31, 2020

rachitnigam commented Dec 31, 2020

cgyurgyik commented Jan 1, 2021 • edited Loading

rachitnigam commented Jan 1, 2021 • edited Loading

rachitnigam commented Jan 3, 2021 • edited by cgyurgyik Loading

cgyurgyik commented Jan 6, 2021

cgyurgyik commented Jan 6, 2021 • edited Loading

sampsyo commented Jan 7, 2021

rachitnigam commented Jan 27, 2021

cgyurgyik commented Jan 27, 2021

cgyurgyik commented Jan 28, 2021 • edited Loading

rachitnigam commented Jan 30, 2021

Lower functions to FuTIL's `invoke`. #340

Lower functions to FuTIL's `invoke`. #340

cgyurgyik commented Dec 29, 2020 •

edited

Loading

cgyurgyik commented Dec 30, 2020 •

edited

Loading

cgyurgyik commented Jan 1, 2021 •

edited

Loading

rachitnigam commented Jan 1, 2021 •

edited

Loading

rachitnigam commented Jan 3, 2021 •

edited by cgyurgyik

Loading

cgyurgyik commented Jan 6, 2021 •

edited

Loading

cgyurgyik commented Jan 28, 2021 •

edited

Loading