[llvm] [LoopInterchange] Update the direction of undistributed loop to EQ (PR #78951)

via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 26 02:07:28 PST 2024


ShivaChen wrote:

> > > > > Skipping the scalar direction is incorrect. Scalar dependencies get carried from every iteration to every iteration, so they **must** be treated more conservatively than a `=` dependence.
> > > > > I think this problem should be solved in the loop interchange pass itself where if the candidate pair of loops is nested inside other loops, and those outer loop IVs don't contribute to the index calculations in the pair of loops, then the dependence entries corresponding to the outer loops should be ignored.
> > > > 
> > > > 
> > > > Thanks for pointing the direction. :-) Could you help me to check does the latest commit as you expected?
> > > 
> > > 
> > > I'm saying let's not modify DependenceAnalysis. The custom handling should be done in Loop Interchange to ignore dependencies at outer levels when they don't matter to the legality of interchange.
> > 
> > 
> > I try to implement without modifying DependenceAnalysis and figure out that LoopInterchange rely on normalize() to enable few optimization opportunities. normalize() didn't happen because the outer loop is the initial value DVEntry::ALL. Currently, normalize() is part of DependenceAnalysis which allow the function to update private DV variable.
> > Setting non-constributed(IV didn't affect instructions) loops direction to NONE for each dependency by scanning the SCEV form of the pointers of Src and Dst instructions instead of initial value ALL seems generally correct for DependenceAnalysis.
> > Or LoopInterchange should explore the way to legalize interchange without normalize? Thanks.
> 
> What would the semantics of `DVEntry::NONE` be? It cannot be treated less pessimistically than `ALL` because the same memory locations get modified in every iteration of the outer loop! It's important for DenepdenceAnalysis to remain conservatively correct in the results in produces, regardless of the consumer of that analysis.
> 
> IMHO, how loop interchange deals with the "non-contributing" outer loops is an implementation issue inside loop-interchange itself. One solution might be to have its own normalize function, so you construct the dependence matrix, prune it (eg. by replacing the `*` with `=` in that entry), then normalize it again.

Have created normalize function in interchange. Thanks for the advice. :-)

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


More information about the llvm-commits mailing list