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

[Sushant Gokhale via llvm-commits]

sushgokh wrote:

> > If we want to limit the scope of fusion to just adjacent loops, then the checks can be completely removed I think. But in the given example(or the issue IR), there is much scope for improvement at the same loop depth level. For instance, post first fusion, we have 3 loops in the same sequence in the candidate set:
> > ```
> > L3
> > L4
> > L12
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > There is still scope for merging L3/L4 and then L34 can be merged with L12. So, basically, this is a recursive procedure. By relaxing the assertions, we would be allowing such fusions by inserting plausible candidates for fusion.
> 
> I am trying to understand your concern here. IIUC you are saying `isAdjacent` condition is not enough because if we limit ourselves to that we may not insert all the loops above into the same CandidateSet and then we will lose the opportunity. Is that correct?

Yes, right.

To reiterate what I would like to say, checking  for adjacency is just for actual fusion. Dominance checking  is for preparing set of plausible candidates for fusion **iteratively** (i.e. even the fused candidate can be candidate for further fusion as is the case here). There are other ways to prepare plausible candidate set at every step of the pass but for now, lets get rid of this assert. Lets proceed  one step at a time.


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