How to handle the states

[HahaLan97]

In CIRCT, the following code is legal:

hw.module @mac(in %in0: i32, in %in1: i32, out out:i32)
{
    %0 = comb.mul %in0, %in1 : i32
    %1 = comb.add %0, %1 : i32
    hw.output %1 : i32
}

As you can see that the addition takes the result as the one operand as well, which is a quite common impl of MAC operation. However, in mlir/lib/IR/Verifier.cpp, this is not allowed, which means if I write:

dfg.operaetor @mac inputs(%in0: i32, %in1: i32) outputs(%out: i32)
{
    %0 = arith.muli %in0, %in1 : i32
    %1 = arith.addi %0, %1 : i32
    dfg.yield %1 : i32
}

This is illegal. To support this, I think I have to make the region a GraphRegion. I'm not so sure if we should do this if we want to allow ops like scf.if in the region, what you guys think? @Feliix42 @KFAFSP

[HahaLan97]

The commit is an incorrect work-around for a specific usage for now.

[HahaLan97]

This error is raised by the SSACFG verifier and make the region a GraphRegion will solve this. However, we don't want this for OperatorOp or ProcessOp. for this usage, we need something from the last loop, we need to think about how to handle the state. And how the lowering will look like.

1. For ProcessOp, the state should be easily handled as iter_args as in scf ops, which should only make sense in LoopOp.
2. For OperatorOp, the state could be a new block argument. And an optional initialization region to yield trivial constants.