Compiling to CoreIR changes the circuit representation

[rsetaluri]

The following code

class Foo(m.Circuit):
    T = m.Array[8, m.Bits[6]]
    S = m.Array[4, m.Bits[6]]
    io = m.IO(
        I=m.In(T),
        O=m.Out(S),
    )
    io.O @= io.I[:4]

print (Foo.O.trace())
m.compile(Foo.name, Foo, output="coreir")
print (Foo.O.trace())

prints out

Foo.I[slice(0, 4, None)]
array([Foo.I[0], Foo.I[1], Foo.I[2], Foo.I[3]])

Functionally of course these are the same. Would it be possible for the compilation be side-effect free in this regard?

---

P.S. the reason this came up is that I was doing a test for MLIR where I compiled to CoreIR first, then to MLIR. In the MLIR compiler, when tracing an array connection, we switch on if the driver is a slice or if it's anonymous. If it's a slice we emit an ArraySliceOp (vs. a sequence of ArrayGetOp's). Therefore, I was seeing different results when I compile to CoreIR before vs. not.

It's not a huge problem for me -- I can just always emit a sequence of ArrayGetOp's. But I figured it would be nice to have the compilation be side-effect free anyway.

[leonardt]

This would suggest that some code path in the coreir compilation is causing the array to be flattened

[leonardt]

(If this doesn't happen in the MLIR code path, perhaps it's fine to just leave this as is and for your test just do MLIR first?)

[rsetaluri]

(If this doesn't happen in the MLIR code path, perhaps it's fine to just leave this as is and for your test just do MLIR first?)

yes, shouldn't be blocked on it, just recording it here