DFG Generation Issues

[ShangkunLi]

Hi~ Cheng,

I am trying to modify the DFG generator and I find some problems about existing generator, together with some potential solutions:

1. Considering the features and existing CGRA mapper, it seems that we only need to consider accelerating loops on CGRA (targetEntireFunction is accttually a dead parameter). So we can directly utilize the loop information stored in targetLoops for DFG generation instead of traversing each BB in the function, which is error-proning as mentioned below.
2. Take the DFG for fft (fig below) as an example. I find that for the br instruction, it has 8 control edges, which is inconsistent with the fft.ll.

3. I want to traverse loops instead of BBs to generate DFGs. For those operands don't belongs to this BB, just create a new node (e.g. const node) to handle the control flow.
4. I think this way may also solve the data dependency (e.g. index increment) between consecutive loop iterations during mapping process. And it is more friendly for scale-out architecture because you can offload each loop to a small PEA (PE array).

Just want to see if you have any other suggestions for these problems. If not, I may modify the code immediately.

[tancheng]

Hi Shangkun, thanks for the insights and planning!

1. Why targetEntireFunction is accttually a dead parameter? It is passed in the DFG and try to ignore certain IR based on whether it is belonging to a loop body I guess?
2. "utilize the loop information" can avoid traversing the BBs? Then how would the control flow (if/else within a loop body) be supported? I guess the fundamental "utilize the loop information" implementation also needs to somehow traversing the BBs?
3. fft.ll has less control flows? I probably additionally add new control flows to all the sibling BBs that on the if/else paths to guarantee the correctness. Let's elaborate on this issue with code snippet? Or schedule a meeting talk about this?
4. "traverse loops instead of BBs to generate DFGs", let's talk about this in Google meeting?
5. @MeowMJ already implement some control flow-related nodes combination. I think you two are solving the issue in two directions. Also, I don't think this is an issue, it is necessary, and your two's solutions are the optimization in different context imo.

[ShangkunLi]

Thanks a lot for your time and reply!

1. Oh, sorry about the targetEntireFunction parameter, I missed some important code.
2. Sure we can schedule a google meeting, and I may elaborate my thoughts with you.