cucapra/dahlia

Memory banking out-of-bounds

cgyurgyik opened this issue · 2 comments

Program

// fuse a.fuse -b=futil --lower
decl A: bit<32>[4 bank 2];
let x0 = A[0];
let x1 = A[2];

Actual Output

[Type error] [Line 4, Column 12] Index out of bounds for `A0'. Memory size is 2, iterator max val is 2
let x1 = A[2];
           ^

Expected Output

I think this is incorrect. A has size 4, which is banked into two memories,
A0 and A1. However, the only way for Dahlia to access A1[0] is to call A[2], because of stripping logical indices:

A[0] => A0[0]
A[1] => A0[1]
A[2] => A1[0] # <--
A[3] => A1[1]

I imagine the fix will be making a mapping from logical indices to banked memory indices, so that the correct memory is accessed at the FuTIL level.

Just a random thought: a bit of information that might help narrow down the bug is knowing whether the error occurs (a) without lowering and (b) when targeting a C++ backend. (I'm guessing no and yes?)

Got it. This original post was mostly me confirming that this is actually a bug.

With fuse a.fuse -b=futil:

[Type error] [Line 4, Column 10] Bank 0 for physical resource `A' already consumed.
let x1 = A[2];
         ^

`A' originally had 1 resource(s).

Previous locations that consumed bank 0:

[3.10] Required 1 resource(s):
let x0 = A[0];
         ^

Last gadget trace was:
[{0}]
[{0}]

I also tried it by changing the last line of the program to let x1 = A[3];, and got a completely different error:

[Impossible] [Enclosing(fuselang.backend.futil.FutilBackendHelper#emitArrayDecl):Line(96)] Banked memories should be lowered. Did you pass the `--lower` flag to the compiler?.. This should never trigger. Please report this as a bug.

I'm pretty deep into NTT land right now; I'm going to come back to this at a later point.