[llvm] [LoopFusion] Assert failure in the issue 80301 (PR #167837)

[via llvm-commits]

CongzheUalberta wrote:

> There are 2 scenarios:
> 
> 1. We are preparing the candidate set for the first time
>    If the situation is ( L1 dom L2 ) but (L2 !postdom L1) then they wont get added to the candidate set and I verified this with the same test example(by removing loop bb105 and its preheader/exit ).

ok, thanks for the clarification.
> 2. We are adding the  fused candidate to the candidate set(as being done by this patch)
>    The fusion doesnt happen in this case because legality checks(such as adjacency) fail.
> 
I did not do a deep debugging so correct me if I'm wrong, but I think the reason fusion does not happen is not because adjacency check fails, it is because with your ordering, after the 1st fusion the candidate set becomes `bb8, bb80, bb3` which likely messed up with the for-loop `for (auto FC0 = CandidateSet.begin(); FC0 != CandidateSet.end(); ++FC0)` and caused the code to immediately exit the for-loop, without even considering that `bb8` and `bb80` can be fused. That ordering does not seem entirely correct anyways (should bb3 appeared in the end? Before fuse it appeared at the beginning).

> Now, coming back to the example in the issue. L1/L2/L3/L4 are in the same candidate set. There is one obvious flaw in the function 'isControlFlowEquivalent' in the sense that L1/L2 and L3/L4 are equivalent pairwise but there is no dominance relation between L2 and L3. So, I think this function is not very useful other than as a legality check for fusion.

I'm not sure if that is correct. LLVM is smart enough to determine when L2 is executed then L3 must gets executed, and vice versa.


One more thing: this PR gives non-deterministic to the ordering in the candidate set, e.g., when `DT->dominates(LHSEntryBlock, RHSEntryBlock)`, it could happen that LHS will be ordered before or after RHS. This seems a bit counter-intuitive to me. Maybe one way to fix the motivative issue is just to drop the fused loop from the candidate set when the ordering cannot be determined, but I need to think more.


https://github.com/llvm/llvm-project/pull/167837