Legality: Currently it can fuse two adjacent loops whose iteration spaces
are same and are at same depth.
Dependence legality: Currently, dependence legality cannot be checked across
loops. Hence the loops are cloned along a versioned path, unconditionally
fused along that path and then the dependence legality is checked on the
fused loop keeping the instructions from original loops in context. Fusion
is illegal if there is a backward dependence between memory accesses whose
source was in first loop and sink was in second loop.
Currently, LoopAccessAnalysis is used to check dependence legality.
Profitability: Yet to be added.
Further, based on legality and profitability success, the fused loop is
either retained or removed. If runtime checks are necessary, both original
and fused loops are retained; otherwise the original loops are removed.
Currently, I have scheduled the fusion pass after distribution pass. Such a
schedule negates the effect of the other pass, but given that the
distribution (and fusion) pass is experimental and off by default, I felt it
was okay to schedule that way till a global profitability is implemented.