[llvm] [LoopVectorize] Add support for vectorisation of more early exit loops (PR #88385)

[David Sherwood via llvm-commits]

david-arm wrote:

> Starting to think about the code for the dependence/memory analysis, I was wondering if this could be generalized a bit more separately. AFAICT the dependence analysis and runtime check generation part of LAA does not really care if there are early exits, as long as we can compute the symbolic max, which should be safe to use instead of the exact BTC: #93499
> 
> With that, it seems like `isAnalyzableEarlyExitLoop` and `mayFault` would be better placed outside LAA?

I agree with trying to break this patch down and making LoopAccessAnalysis as generic and untied to the vectoriser as possible, but I will definitely need to do work in LoopAccessAnalysis to provide the right information for users of it. For example, LoopAccessAnalysis does all the analysis of loads and stores in the loop, not LoopVectorizationLegality where we now test for uncomputable backedge counts. We still need to determine whether or not the loop has an uncountable exit and, if so, whether there are any memory accesses after the exit, which is something more suited to LoopAccessAnalysis. If we move all the analysis into LoopVectorizationLegality then we basically have to duplicate the same work of walking through all the instructions in all the blocks that already happens in canAnalyzeLoop. In this new world I will still need to calculate the earliest uncountable exiting block in LoopAccessAnalysis and track post-exit memory accesses so that in LoopVectorizationLegality we can query the data to make an informed choice. I'll look into doing that, but the main point is that we can't devolve all work into LoopVectorizationLegality.

I may be able to move mayFault, but it does depend upon structures built up by LoopAccessAnalysis and I personally thought that this function might be useful outside of the vectoriser so it wasn't obvious where to move it to.


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