[Polly][PM][WIP] Polly pass registration
Summary:
This patch is a first attempt at registering Polly passes with the LLVM tools. Tool plugins are still unsupported, but this registration is usable from the tools if Polly is linked into them (albeit requiring minimal patches to those tools). Registration requires a small amount of machinery (the owning analysis proxies), necessary for injecting ScopAnalysisManager objects into the calling tools.
This patch is marked WIP because the registration is incomplete. Parsing manual pipelines is fully supported, but default pass injection into the O3 pipeline is lacking, mostly because there is opportunity for some redesign here, I believe. The first point of order would be insertion points. I think it makes sense to run before the vectorizers. Running Polly Early, however, is weird. Mostly because it actually is the default (which to me is unexpected), and because Polly runs it's own O1 pipeline. Why not instead insert it at an appropriate place somewhere after simplification happend? Running after the loop optimizers seems intuitive, but it also seems wasteful, since multiple consecutive loops might well be a single scop, and we don't need to run for all of them.
My second request for comments would be regarding all those smallish helper passes we have, like PollyViewer, PollyPrinter, PollyImportJScop. Right now these are controlled by command line options, deciding whether they should be part of the Polly pipeline. What is your opinion on treating them like real passes, and have the user write an appropriate pipeline if they want to use any of them?
Reviewers: grosser, Meinersbur, bollu
Reviewed By: grosser
Subscribers: llvm-commits, pollydev
Tags: #polly
Differential Revision: https://reviews.llvm.org/D35458
llvm-svn: 309826
2017-08-02 23:52:25 +08:00
|
|
|
#ifndef FUNCTION_ANALYSIS
|
|
|
|
|
#define FUNCTION_ANALYSIS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
|
|
|
|
FUNCTION_ANALYSIS("polly-detect", ScopAnalysis())
|
|
|
|
|
FUNCTION_ANALYSIS("polly-function-scops", ScopInfoAnalysis())
|
|
|
|
|
#undef FUNCTION_ANALYSIS
|
|
|
|
|
|
|
|
|
|
#ifndef FUNCTION_PASS
|
|
|
|
|
#define FUNCTION_PASS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
|
|
|
|
FUNCTION_PASS("polly-prepare", CodePreparationPass())
|
|
|
|
|
FUNCTION_PASS("print<polly-detect>", ScopAnalysisPrinterPass(errs()))
|
|
|
|
|
FUNCTION_PASS("print<polly-function-scops>", ScopInfoPrinterPass(errs()))
|
|
|
|
|
#undef FUNCTION_PASS
|
|
|
|
|
|
|
|
|
|
#ifndef SCOP_ANALYSIS
|
|
|
|
|
#define SCOP_ANALYSIS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
|
|
|
|
SCOP_ANALYSIS("polly-ast", IslAstAnalysis())
|
|
|
|
|
SCOP_ANALYSIS("polly-dependences", DependenceAnalysis())
|
|
|
|
|
#undef SCOP_ANALYSIS
|
|
|
|
|
|
|
|
|
|
#ifndef SCOP_PASS
|
|
|
|
|
#define SCOP_PASS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
2017-08-10 22:45:09 +08:00
|
|
|
SCOP_PASS("polly-export-jscop", JSONExportPass())
|
|
|
|
|
SCOP_PASS("polly-import-jscop", JSONImportPass())
|
[Polly][PM][WIP] Polly pass registration
Summary:
This patch is a first attempt at registering Polly passes with the LLVM tools. Tool plugins are still unsupported, but this registration is usable from the tools if Polly is linked into them (albeit requiring minimal patches to those tools). Registration requires a small amount of machinery (the owning analysis proxies), necessary for injecting ScopAnalysisManager objects into the calling tools.
This patch is marked WIP because the registration is incomplete. Parsing manual pipelines is fully supported, but default pass injection into the O3 pipeline is lacking, mostly because there is opportunity for some redesign here, I believe. The first point of order would be insertion points. I think it makes sense to run before the vectorizers. Running Polly Early, however, is weird. Mostly because it actually is the default (which to me is unexpected), and because Polly runs it's own O1 pipeline. Why not instead insert it at an appropriate place somewhere after simplification happend? Running after the loop optimizers seems intuitive, but it also seems wasteful, since multiple consecutive loops might well be a single scop, and we don't need to run for all of them.
My second request for comments would be regarding all those smallish helper passes we have, like PollyViewer, PollyPrinter, PollyImportJScop. Right now these are controlled by command line options, deciding whether they should be part of the Polly pipeline. What is your opinion on treating them like real passes, and have the user write an appropriate pipeline if they want to use any of them?
Reviewers: grosser, Meinersbur, bollu
Reviewed By: grosser
Subscribers: llvm-commits, pollydev
Tags: #polly
Differential Revision: https://reviews.llvm.org/D35458
llvm-svn: 309826
2017-08-02 23:52:25 +08:00
|
|
|
SCOP_PASS("print<polly-ast>", IslAstPrinterPass(outs()))
|
|
|
|
|
SCOP_PASS("print<polly-dependences>", DependenceInfoPrinterPass(outs()))
|
|
|
|
|
SCOP_PASS("polly-codegen", CodeGenerationPass())
|
|
|
|
|
#undef SCOP_PASS
|