[feat] FU-level fusion

[HobbitQia]

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:

1. Pattern Extraction: Extracts fused operation patterns from the module and linearizes them via topological sort.
2. Standalone Operation Extraction: Collects standalone operations not inside fused patterns for hardware coverage.
3. Template Creation: Greedily merges patterns into shared hardware templates using cost-based accommodation with DFS mapping search.
4. Connection Generation: Generates optimized slot connections based on pattern dependencies with bypass support.
5. Execution Plan Generation: Creates parallel execution stages by grouping operations at the same topological level.
6. JSON Output: Writes hardware configuration including templates, connections, and execution plans to JSON file.

[tancheng]

Define/comment HW slot with example. FU in same slot cannot be executed at the same time. Slot is good for which case.

[HobbitQia]

added. u can check it.

[tancheng]

Plz refactor all the variables naming. patternId -> pattern_id

[HobbitQia]

updated.

[tancheng]

Plz remind me, after merging, the II would be improved?

[HobbitQia]

Yes! In test.mlir the rec_mii decreases from 9 to 8 and res_mii decreases from 5 to 3.

If we use the same mapping strategy (customize) the mapping ii will decrease from 12 to 9.

[tancheng]

Can we use this example to show what each field means (maybe draw it), and put it into PR's description?

[HobbitQia]

Field Explanations

Field	Description
template_id	Unique identifier for this template
instance_count	Number of instances each pattern
supported_single_ops	Individual operations this template can execute standalone
supported_composite_ops	Fused patterns this template can execute
slots	Array of slot definitions with their supported operations
slot_connections	Data routing paths between slots
pattern_execution_plans	Detailed execution schedules for each pattern

---

Execution Plan Fields

Field	Description
pattern_id	Pattern being executed
pattern_name	pattern name
slot_mapping	Maps operation index to slot ID: [op0→slot0, op1→slot1, ...], e.g. [1, 2] means we will use slot 1 and slot2 to execute op0 and op1 of this pattern.
execution_stages	Ordered stages of execution
parallel_slots	Slots executing in this stage (can be multiple for parallel ops)
parallel_ops	Operations executing in this stage

---

Note that parallel_ops is corresponding to parallel_slots. e.g.,

Example

Template 1 (instance_count: 3)
══════════════════════════════════════════════════════════════════

Pipeline Structure:
┌────────────────┐      ┌─────────────────────┐      ┌─────────────────────┐
│    Slot 0      │ ──── │       Slot 1        │ ──── │       Slot 2        │
│     icmp       │      │  grant_predicate    │      │  grant_predicate    │
└────────────────┘      └─────────────────────┘      └─────────────────────┘

Supported Patterns:
  - Pattern 1: icmp->grant_predicate->grant_predicate (full pipeline)
  - Pattern 3: icmp->grant_predicate (bypass slot 1)
  - Pattern 2: grant_predicate->grant_predicate (bypass slot 0)

Pattern 1 (icmp->grant_predicate->grant_predicate) shows parallel execution:

Stage 0: Slot 0 executes icmp
Stage 1: Slot 1 AND Slot 2 execute grant_predicate IN PARALLEL
         (both depend only on icmp output)

{
  "pattern_id": 1,
  "pattern_name": "fused_op:icmp->grant_predicate->grant_predicate",
  "slot_mapping": [0, 1, 2],
  "execution_stages": [
    {
      "stage": 0,
      "parallel_slots": [0],
      "parallel_ops": ["neura.icmp"]
    },
    {
      "stage": 1,
      "parallel_slots": [1, 2],
      "parallel_ops": ["neura.grant_predicate", "neura.grant_predicate"]
    }
  ]
}

Note: In Stage 1, slots 1 and 2 execute simultaneously because both grant_predicate operations have the same topological level (both depend on icmp).