Dear all,
please find below the meeting notes form the Polly BoF (as taken by Michael Kruse). Comments and feedback is very much appreciated.
Best,
Tobias
Status update
* Polly late in pipeline
* Uses TargetTransformInfo
* Part of the release process
* isl: C++ interface, MIT licenced, improved scheduler
* Polly integration plan; result: isl and Polly available in each build
* Better integration into LLVM
Discussion
* Discussion topics?
* Move Polly into LLVM:
* See the proposal at: (_http://lists.llvm.org/pipermail/llvm-dev/2017-September/117698.html_)
* Future ideas:
* Do loop transformations in one phase, collect assumptions/safety conditions
* Tobias: Generalize assumption collection -> framework?
* Speculative optimizations without materializing them?
* Can the compiler/analysis recommend to the user to add pragmas?
* Hal: Great set of features
* There are other possibilities for loop optimizations than Polly
* Tobias: It is possible to write complex loop transformations without Polly, but writing complex loop transformations can be difficult
* Tobias: Polyhedral optimization is not a totally stupid option 
* Tobias: Maybe different loop optimization phases, eg different before inliner
* Tobias: More loop benchmarks in test-suite
* Tobias: Explore different options, eg. mixed-lp solvers
* Why polyhedral model to do basic loop transformations?
* Hal: Helps deriving safety conditions
* Experience: People like automatically derived safety conditions, even if transformation is not performed automatically
* Hal: User-directed loop optimizations (#pragmas), less analysis needed
* What's the next step?
* Tobias: Figure out what to do with isl; which subdirectory
* Adjust the LLVM pass pipeline (eg. partial unrolling after inlining, fix bugs)
* Discussions about how to rearrange LLVM (e.g. TargetTransformInfo for caches, polyhedral value analysis)
* With SVN move, how much bigger does the repository become?
* Tobias: In conclusion, not a big difference (guess: 5-10% increase)
* Current performance of Polly on SPEC benchmarks, compile time
* clang bootstrap regression 6%
* aosp buildbot
* 3 minutes per program, to find compile time issues
* some regression 20%-30%
* ScopDetection guards polyhedral modeling
* Often compile time regression because of loop versioning
* Some benchmarks 80%-90% speedup
* Is isl evolving in LLVM tree, and how often?
* Tobias: Need ability to adapt changes quickly (bugs...)
* What could be the first upstreamed patches.
* Tobias: SVN move of Polly, iterative integration: isl, polyhedral value analysis, Parts of Polly as separate low-level analysis.
* isl integration is a requirement?
* Yes; isl as an independent component
* llvm integration into llvm source tree preferable over external library; use latest version and possibly make own changes (good idea?)
* Is there a use case of isl outside Polly?
* Johannes: yes: polyhedral value analysis
* Is Polly history preserved?
* Yes
* Zino: With wrapper it is easier put isl into LLVM
* Tobias: More control over functionality, C++ class hierarchy
* Tobias: is currently update when convenient
* Do we want to have polyhedral stuff in LLVM?
* Do we want to have a single community (stop polly-dev)?
* Practical integration of Polly and (polyhedral tooling in general)?
* Integration with LLVM / upsteaming to mainline LLVM?
Best,
Tobias