Refactor Single Loop Fusing Logic

[ShangkunLi]

We provide a stream-based loop controller here for a single loop.

We embed all the constant loop info as attributes into the loop_control operation, e.g., step, start, end, etc.

This can greatly reduce the fan-ins for loop_control and get better mapping results.

[tancheng]

Can we also enable the interpreter to verify the fusion's functionality?

[ShangkunLi]

Can we also enable the interpreter to verify the fusion's functionality?

Sure~ But can we do it after I finish the experiment evaluation? I may create a new pr about transforming our IR into a steering-control-based manner tomorrow.

Filed an issue about that #143

[tancheng]

I may create a new pr about transforming our IR into a steering-control-based manner tomorrow.

Why we need control-based? I thought this PR's change is for data flow?

[ShangkunLi]

I may create a new pr about transforming our IR into a steering-control-based manner tomorrow.

Why we need control-based? I thought this PR's change is for data flow?

Yes, I developed a pass to convert our dataflow ir into steering control ir, like RipTide. It may lay the foundations for a further hybrid execution model~

[tancheng]

I may create a new pr about transforming our IR into a steering-control-based manner tomorrow.

Why we need control-based? I thought this PR's change is for data flow?

Yes, I developed a pass to convert our dataflow ir into steering control ir, like RipTide. It may lay the foundations for a further hybrid execution model~

So basically two PRs:

• Verifying loop_control in dataflow fashion via our dataflow interpreter
• Transform loop_control into steering-based ctrl logic
  • also verify via our ctrl-flow interpreter

Am I right?

[ShangkunLi]

So basically two PRs:

• Verifying loop_control in dataflow fashion via our dataflow interpreter

Correct for this.

• Transform loop_control into steering-based ctrl logic

  • also verify via our ctrl-flow interpreter

Am I right?

It is to convert all the predicate-based IR into steer-control-based IR, not just the loop_control.

[tancheng]

So basically two PRs:

• Verifying loop_control in dataflow fashion via our dataflow interpreter

Correct for this.

• Transform loop_control into steering-based ctrl logic

  • also verify via our ctrl-flow interpreter

Am I right?

It is to convert all the predicate-based IR into steer-control-based IR, not just the loop_control.

one qq, maybe we discussed before. Steering-based sounds like ctrl-flow mixed with dataflow, why do we tune our dataflow into mixed ctrl-flow + dataflow? why not directly lower pure ctrl-flow into steering-based flow?

[ShangkunLi]

So basically two PRs:

• Verifying loop_control in dataflow fashion via our dataflow interpreter

Correct for this.

• Transform loop_control into steering-based ctrl logic

  • also verify via our ctrl-flow interpreter

Am I right?

It is to convert all the predicate-based IR into steer-control-based IR, not just the loop_control.

one qq, maybe we discussed before. Steering-based sounds like ctrl-flow mixed with dataflow, why do we tune our dataflow into mixed ctrl-flow + dataflow? why not directly lower pure ctrl-flow into steering-based flow?

Oh, we discussed it last Tuesday. If we choose to directly lower from the neura CDFG representation like RipTide, it would be extremely complex as we need to handle many things, including memory access ordering, ensuring transformation completeness, detecting the correct insertion points for steer ops, etc.

And using pattern-matching-based methods to convert current predicate-based ir to the new dataflow ir would be much easier. And, we can guarantee the transformation is complete.