[llvm] [LoopInterchange] Increment isDirectionNegative check to next level for scalar direction (PR #78951)

[via llvm-commits]

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.


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