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

Calyx back-end issues #427

Open
Mark1626 opened this issue Mar 21, 2024 · 2 comments
Open

Calyx back-end issues #427

Mark1626 opened this issue Mar 21, 2024 · 2 comments

Comments

@Mark1626
Copy link
Collaborator

I noted these two issue when I was trying to add float support in Dahlia (Calyx backend)

1. Hoist memory pass issue

The following does not pass with --lower flag.

decl a: float[128];
decl b: bit<10>[128];
decl c: float[128];

for (let i:bit<8>=0..128) {
    c[i] := a[b[i]];
}

Error

[Type error] [Line 0, Column 0] `b_read0' is not bound in scope.
<undefined position>

Root cause seems to be the Hoist pass, b_read0 has not been created

===============Original===============
decl a: float[128];
decl b: bit<10>[128];
decl c: float[128];
for (let i: bit<8> = 0 .. 128) {
  c[i] := a[b[i]];
}
======================================
===============Hoist memory reads===============
decl a: float[128];
decl b: bit<10>[128];
decl c: float[128];
for (let i: bit<8> = 0 .. 128) {
  let a_read0 = a[b_read0];
  c[i] := a_read0;
}


2. Incorrect usage of signed Calyx primitives

The following generates Calyx IR

decl a: bit<10>[128];
decl b: bit<10>[128];
decl c: bit<10>[128];

for (let i:bit<8>=0..128) {
    c[i] := a[i] & b[i];
}

The Calyx IR contains a std_sand primitive which seems to be not present in the current Calyx primitives

import "primitives/core.futil";
import "primitives/memories/seq.futil";
import "primitives/binary_operators.futil";
import "P32.futil";
component main() -> () {
  cells {
    @external(1) a = seq_mem_d1(10,128,8);
    a_read0_0 = std_reg(10);
    add0 = std_sadd(8);
    and0 = std_sand(10);
   ...
   ...
   ...
@rachitnigam
Copy link
Member

Thanks! (1) seems like a bug in lowering while (2) is probably in the backend. For (2), we basically attempt to generate the string name of the operator based on whether or not the operands are signed or not (adding the s if they are). For logical operators like &, I think we should probably not generate the s?

@Mark1626
Copy link
Collaborator Author

  1. Seems to be because of this function. I feel the Calyx backend code needs some restructuring, we seem to lose information about the operator

def binop(op: String, bitwidth: Int, signed: Boolean): Calyx.CompInst =
Calyx.CompInst(
s"std_${if signed then "s" else ""}$op",
List(bitwidth)
)

I'll try to address both these issues in a PR when I get some time

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

No branches or pull requests

2 participants