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

[via llvm-commits]

CongzheUalberta wrote:

> > > With this patch, we could have fusion candidates even if they do not have the proper control flow. In this case, we need to check the control flow of the candidates on the fusion step. Does loop fusion do this check on the fusion step?
> > 
> > 
> > Yes, 'isAdjacent' should be the function doing the check. I cant think of scenario where they are not control flow equivalent yet adjacent.
> 
> If our codegen is limited to adjacent loops, why do we put non-adjacent loops in a candidate set? If we just put adjacent loops in the candidate set, do we lose any opportunity?
> 
> We can always extend fusion in the future, and make it to catch more candidates.
> 
> Do I miss something here? (@CongzheUalberta what do you think?)

Currently llvm does not have the capability to fuse non-adjacent loops that are control flow equivalent (fusing non-adjacent loops would be something nice to have). However I think it is still good to put non-adjacent loops that are control flow equivalent in the candidate set, which opens the door and could be used as the stepping stone for future extension of fusing non-adjacent loops. 

If we only put adjacent loops in the set, we would lose the opportunity extending to fusing non-adjacent loops. In that case when we want to extend to non-adjacent loops down the road, we would have to revert the pass to the state as of now and then we essentially would end up with the same issue as what we are facing now.

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