This is an archive of the discontinued LLVM Phabricator instance.

[Polly] Loop versioning after code generation (WIP)
AbandonedPublic

Authored by Meinersbur on Nov 16 2015, 10:46 AM.

Details

Reviewers
None
Summary

Loop versioning modifies the scop, especially the PHI nodes in the entry and exit block. Code generation must take this into account and test for multiple cases where the PHIs could have landed which can also depend on the code surrounding the scop. Not considering all cases has been a source of many bugs.

With this patch we generate code before modifying the scop region into a region disconnected from the original code. Only after the code has been created, it is connected as an alternative of the original scop region.

Going further with this idea, we could generate all SCoPs in a function before connecting them in order to not require to verify whether other detected SCoPs are still valid.

Diff Detail

Event Timeline

Meinersbur retitled this revision from to [Polly] Loop versioning after code generation (WIP).
Meinersbur updated this object.
Meinersbur added a project: Restricted Project.
Meinersbur added subscribers: pollydev, llvm-commits.

Currently failing 71 unit tests (none adapted to possibly required changes). Working on the SCEVs of IslNodeBuilder::OutsideLoopIterations which expand into the original scop region, but are used in the generated one.

Meinersbur abandoned this revision.Dec 14 2015, 7:13 AM

This may cause problems with ScalarEvolution which is not propared to generate code in (temporarily) disconnected blocks. Since we are not in control of SE to reliably correct this, we abandon this approach.

To bad, I thought this was a nice solution.

One of the students I advice currently tackles a similar problem when SE
is used to synthesise code in a parallel subfunction... I'll let you
know once we figured that out.

To bad, I thought this was a nice solution.

One of the students I advice currently tackles a similar problem when SE
is used to synthesise code in a parallel subfunction... I'll let you
know once we figured that out.

One of my other suggestions was to generate the code in a separate function which is to be inlined by LLVM afterwards. Unfortunatelt it is forbidden for function passes to touch (or create) functions they were not invoked on.

Polly has to become a SCC pass anyway in order to make parallelization
valid (and allow inter-procedural analysis), thus this should not be a
concern. However, it seems odd and expensive to create a function only
to inline it again, so we might not want to do that.