[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#713119, @Meinersbur wrote:

> Thanks for getting this for started. The part of adding those passes to the new pass manager's pipeline must be done in RegisterPasses.cpp, but all passes must be registered to the new pass manager, otherwise it cannot use them.


Pass Registration is still a pending issue. Until https://reviews.llvm.org/D11032 is ready to land, there is no defined way to set up a polly pipeline.

> Note that we have two correctness issues that are fragile with the pass managers:
> 
> 1. Polly's codegen can change the IR of other SCoPs. Particularly it can make previously detected scops invalid. Thats why the sequence must be:

This is precisely the problem a ScopXManager would solve...

> CodeGeneration of A can invalidate B, resulting in miscompiles because the IR of B was changed and does not correspond to its ScopInfo anymore.

... however this violates fundamental assumptions both the new and(!) the old pass managers make. It's an upstream miscompile or crash waiting to happen. In what way do SCoPs specifically interact? If there is no way to break that dependence, we can't run our own SCoP pipeline and must widen the IRUnit of the analyses to Function.

> 2. Polly does a bad job preserving analyses. It does not create new regions and loops in generated code. There is currently an ugly hack called NoopBarrier added to the pass pipeline that effectively throws away all analyses with the legacy pass manager. I get miscompiles when that barrier pass is removed. The new pass manager just caches all analyses.

This is a non-issue. The new PM pessimistically invalidates all cached analysis results after a transfrom by default.


https://reviews.llvm.org/D31459