[PATCH] D31459: [Polly][NewPM] Port ScopDetection to the new PassManager

[Philip Pfaffe via Phabricator via llvm-commits]

philip.pfaffe added a comment.

In https://reviews.llvm.org/D31459#713425, @Meinersbur wrote:

> I was trying to ask Chandler Carruth ask about this in the Hacker's Lab. Unfortunately I already asked too many questions and he preferred to let other people ask questions as well.


I've discussed this a bit with Chandler. If my patch lands it will enable pass registration. Hopefully that'll happen soonish.

> What is ScopXManager? If it is a single pass (Tobias suggested "-polly-sched") that would run all the other passes itself, then we have full control and can run in any order we like. However, we then also don't need to convert to existing passes to the new pass manager, they would be not be scheduled by any LLVM's pass manager anymore.

The X stands for Pass and Analysis. I was thinking about adding these Managers to keep the pipelining behavior as it was before. But this depends on the issues below.

> This happens with Loop passes all the time. Loop passes can create new loops (loop distribution) or remove them as it they like, as long as the LoopInfo remains consistent.

Loop passes modify the current loop nest, add loops to it or delete it or its children. They don't affect entirely different loops in the same function, I think. Either way, the PM is flexible enough to allow for adding and removing Scops from the current worklist.

> What I can think of is that the exit block of one SCoP is the entry block of the next one (and they are not combined to a single SCoP, e.g. because there is another edge from somewhere to that block). After codegen, there will be a merge block (`polly.merge_new_and_old`), combining the control flow from the the loop versioning branch, which would be the new entry block of the second. However, if ScopInfo already ran on the second SCoP, it will still reference the original entry block, which landed somewhere else, e.g. as the original code section.

If we keep ScopInfo as a ScopPass, this cannot happen.

> Because pass dependencies are mostly transitive, invalidating all analysis would mean it also invalidates ScopDetection and we would try to re-detect the output of CodeGeneration. This is actually because polly passes have to preserve _all_ analyses used by any polly pass. It is also inefficient because we'd need to run all these analyses multiple times.

It wouldn't necessarily mean that. If, as discussed above, I add a ScopPass pipeline, ScopDetection would naturally be preserved. Inside a ScopPass individual analyses can be preserved, if we can pessimistically guarantee that that's sound. Frequent cache invalidation may happen, and it does in the current https://reviews.llvm.org/owners/package/2/, https://reviews.llvm.org/owners/package/3/ pipelines. However, so far the performance impact is negligible.

Fundamentally I don't see anything of this as a blocker to using a ScopPassManager. I'll thus move forward with building one and porting the existing passes over to the new Scop pipeline. Any further pointers with regard to SCoP interaction would much appreciated!


https://reviews.llvm.org/D31459