Visible to Intel only — GUID: ddd1582588012187
Ixiasoft
Visible to Intel only — GUID: ddd1582588012187
Ixiasoft
6.9. Loop Fusion
Loop fusion is a compiler transformation in which two adjacent loops are merged into a single loop over the same index range. This transformation is typically applied to reduce loop overhead and improve run-time performance.
Unfused Loops | Fused Loop |
---|---|
|
|
Unfused Loops | Fused Loop |
---|---|
|
|
Loop control structures represent a significant overhead. By fusing two loops, the number of control structures needed for the loops is reduced from two to one, reducing this overhead. The main goal of reducing the number of control structures is save FPGA area for your design while still maintaining (ideally increasing) component throughput.
Fusing outer loops introduces parallelism where there was previously none. Combining bodies of two adjacent loops (Lj and Lk) forms a single loop (Lf) with a loop body that spans the bodies of Lj and Lk. This combined loop body creates an opportunity for operations that were serialized across a given iteration of Lj and Lk to execute in parallel In effect, the two loops now execute in lockstep as a single loop, which provides latency improvements.
If inner loops are fused, parallelism is already achieved by pipelined execution of the outer loop iteration. In these cases, the parallelism effect of loop fusion is diminished.
Fusion Criteria
- The loops must be adjacent.
That is, you cannot have a statement Si with side-effects such that Si executes after Lj and before Lk.
- Each loop must have a single-entry point and a single exit point.
For example, loops that contain break statements are not considered for fusion.
- The loops must have no negative-distance dependencies.
That is, for loops Lj and Lk where Lj is defined before Lk, iteration m of loop Lk does not depend on values calculated in iteration m+n (where n>0) of loop Lj.
Automatic Loop Fusion
The Intel® HLS Compiler fuses adjacent loops with equal trip counts automatically if the compiler analysis of your component determines that fusing the loops is profitable.
- One of the two loops, but not both, is annotated with the ivdep pragma.
- One of the two loops, but not both, contains stall-free logic.
The Loop Analysis Report in the High-Level Design Reports indicates when loops were fused.
- nofusion pragma
Annotate loops with this pragma to request that the compiler not fuse the annotated loop.
-
Override the compiler profitability analysis and fuse adjacent loops provide that it is safe.
Use the the loop_fuse pragma to tell the compiler to consider fusing adjacent loops with different trip counts.