[feat] FU-level fusion #244
Conversation
…into hardware_merge
| HardwarePattern(int64_t i, const std::string& n, int64_t f); | ||
| }; | ||
|
|
||
| struct HardwareSlot { |
There was a problem hiding this comment.
Define/comment HW slot with example. FU in same slot cannot be executed at the same time. Slot is good for which case.
There was a problem hiding this comment.
added. u can check it.
There was a problem hiding this comment.
hmm, disabling simultaneous execution in one slot is still unnecessary to me. Slots can also be merged or split.
In this context, I am still hesitate to see "slot" in our definition. I feel it over-complicates the design. Can you try to avoid introducing "slot" to see whether the algorithm still works?
There was a problem hiding this comment.
I agree with it. Currently I remove the concept "slot" and when mapping we only consider FUs as building blocks of hardware templates. The results are the same as before without "slot".
include/NeuraDialect/NeuraPasses.td
Outdated
| Algorithm: | ||
| 1. Extract pattern DAGs with topological structure from fused_op regions | ||
| 2. Group patterns by structural similarity (same DAG shape) | ||
| 3. For structurally similar patterns, create hardware templates where |
There was a problem hiding this comment.
refactor "slot" description
| //===- HardwareMergePass.cpp - Hardware Template Merging Pass -------------===// | ||
| // | ||
| // This pass maximizes pattern coverage with minimum hardware cost by merging | ||
| // patterns into shared hardware templates. It supports slot bypassing, |
2 participants
This pass implements the FU-level fusion after DFG-level fusion (PR 194), which aims to find the minimum FU cost that can cover all patterns extracted in previous passes (wrapped in
fused_op).The algorithm can be depicted as below: