Dear LLVM community, hope all of you had a good start into 2018 and a quiet branching of LLVM 6.0. With the latest LLVM release out of the way and a longer development phase starting, we would like to restart the process of including Polly and isl into core LLVM to bring changes in early on before the next LLVM release. Short summary: * Today Polly is already part of each LLVM release (and will be shipping with LLVM 6.0) for everybody to try, with conservative defaults. * We proposed to include Polly and isl into LLVM to provide modern high-level loop optimizations into LLVM * We suggested to develop Polly and isl as part of core LLVM to make interactions with the core LLVM community easier and to allow us to better integrate Polly with the new pass manager. Let me briefly summarize the current status: * Michael sent out an official email to discuss how to best include isl into LLVM (http://lists.llvm.org/pipermail/llvm-dev/2018-January/120408.html) * We sent out the LLVM developers meeting notes (_http://lists.llvm.org/pipermail/llvm-dev/2018-January/120419.html_) * Philip Pfaffe prepared a preliminary patch set for integrating Polly closer into LLVM: _https://github.com/pfaffe/llvm-project-20170507/commits/merge-polly-into-upstream_ (further cleanup needed) * We are working further with ARM (Florian Hahn and Francesco) to upstream the inliner changes needed for the end-to-end optimization of SPEC 2006 libquantum. _https://reviews.llvm.org/D38585_ * Oleksandr, Sven and Manasij Mukherjee started to look into spatial locality * We worked on expanding the isl C++ bindings (_http://repo.or.cz/isl.git/shortlog_). While a first set of patches is already open, further patches will follow over the next couple of weeks. Let me briefly summarize the LLVM developer meeting comments on our proposal (subjective summary) * Most people were interested in having polyhedral loop optimizations being part of LLVM. * Ideas of uses of isl beyond polyhedral loop scheduling were raised (e.g., for polyhedral value analysis, dependence analysis, or broader assumption tracking). Others were interested in the use of polyhedral loop optimization with “learned” scheduling strategies. * Specific concerns were raised that an integration of Polly into LLVM may be an implicit choice of LLVMs loop optimization future. This is not the case. While Polly is today the only end-to-end high-level loop optimization, other approaches can and should explored (e.g., can there be synergies with the region vectorizer?) * How stable/fast/… is Polly today * We build all of AOSP with rather restrictive compile-time limits * Bootstrapping time of clang is regressed by 6% (at most) * Removal of scalar dependences is today very generic and must be sped up in the future * Polly still shows up at the top of the middle-end, but larger compile time regressions are often due to increased code size (and the LLVM backend) * We see non-trivial speedups for hmmer, libquantum, and various linear-algebra kernels (we use gemm-specific optimizations). The first two require additional flags to be enabled. The precise inclusion agenda has been presented here: http://lists.llvm.org/pipermail/llvm-dev/2017-September/117698.html After having merged communities, I suggest to form a loop optimization working group which jointly discusses how LLVM’s loop optimizations should evolve. I would like to invite comments regarding this proposal. Are there any specific concerns we should address before requesting the initial svn move? Best, Tobias
Thanks Tobias, I am really looking forward to trying out the true integrated Polly and I hope to provide good positive feedback. Since I am maintaining an "out of tree" target, I generally update on each release - I call it the Big Bang update because of the difficulties this presents. At the moment our target is based on the v5.0.0 sources, and I hope to update to the v6.0.0 sources very soon. Our target is VLIW with a lot of vectorisation support. Polly in theory should be good for our platform, mainly because the transformations it provides should eventually yield better ILP (more operations per instruction). Previously I have tried Polly with limited benefits, and almost all of the negatives were because the out-of-tree Polly was not engaging TTI into its decision making, and I am very interested in seeing what has been added to TTI for Polly that will allow me to tune its behaviour. Looking forward to using Polly as a first-class citizen of LLVM, and thanks for your huge work in this contribution. MartinO -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tobias Grosser via llvm-dev Sent: 15 January 2018 21:33 To: llvm-dev <llvm-dev at lists.llvm.org> Subject: [llvm-dev] (no subject) Dear LLVM community, hope all of you had a good start into 2018 and a quiet branching of LLVM 6.0. With the latest LLVM release out of the way and a longer development phase starting, we would like to restart the process of including Polly and isl into core LLVM to bring changes in early on before the next LLVM release. Short summary: * Today Polly is already part of each LLVM release (and will be shipping with LLVM 6.0) for everybody to try, with conservative defaults. * We proposed to include Polly and isl into LLVM to provide modern high-level loop optimizations into LLVM * We suggested to develop Polly and isl as part of core LLVM to make interactions with the core LLVM community easier and to allow us to better integrate Polly with the new pass manager. Let me briefly summarize the current status: * Michael sent out an official email to discuss how to best include isl into LLVM (http://lists.llvm.org/pipermail/llvm-dev/2018-January/120408.html) * We sent out the LLVM developers meeting notes (_http://lists.llvm.org/pipermail/llvm-dev/2018-January/120419.html_) * Philip Pfaffe prepared a preliminary patch set for integrating Polly closer into LLVM: _https://github.com/pfaffe/llvm-project-20170507/commits/merge-polly-into-upstream_ (further cleanup needed) * We are working further with ARM (Florian Hahn and Francesco) to upstream the inliner changes needed for the end-to-end optimization of SPEC 2006 libquantum. _https://reviews.llvm.org/D38585_ * Oleksandr, Sven and Manasij Mukherjee started to look into spatial locality * We worked on expanding the isl C++ bindings (_http://repo.or.cz/isl.git/shortlog_). While a first set of patches is already open, further patches will follow over the next couple of weeks. Let me briefly summarize the LLVM developer meeting comments on our proposal (subjective summary) * Most people were interested in having polyhedral loop optimizations being part of LLVM. * Ideas of uses of isl beyond polyhedral loop scheduling were raised (e.g., for polyhedral value analysis, dependence analysis, or broader assumption tracking). Others were interested in the use of polyhedral loop optimization with “learned” scheduling strategies. * Specific concerns were raised that an integration of Polly into LLVM may be an implicit choice of LLVMs loop optimization future. This is not the case. While Polly is today the only end-to-end high-level loop optimization, other approaches can and should explored (e.g., can there be synergies with the region vectorizer?) * How stable/fast/… is Polly today * We build all of AOSP with rather restrictive compile-time limits * Bootstrapping time of clang is regressed by 6% (at most) * Removal of scalar dependences is today very generic and must be sped up in the future * Polly still shows up at the top of the middle-end, but larger compile time regressions are often due to increased code size (and the LLVM backend) * We see non-trivial speedups for hmmer, libquantum, and various linear-algebra kernels (we use gemm-specific optimizations). The first two require additional flags to be enabled. The precise inclusion agenda has been presented here: http://lists.llvm.org/pipermail/llvm-dev/2017-September/117698.html After having merged communities, I suggest to form a loop optimization working group which jointly discusses how LLVM’s loop optimizations should evolve. I would like to invite comments regarding this proposal. Are there any specific concerns we should address before requesting the initial svn move? Best, Tobias _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On Mon, Jan 15, 2018, at 22:53, Martin J. O'Riordan via llvm-dev wrote:> Thanks Tobias, > > I am really looking forward to trying out the true integrated Polly and > I hope to provide good positive feedback. > > Since I am maintaining an "out of tree" target, I generally update on > each release - I call it the Big Bang update because of the difficulties > this presents. At the moment our target is based on the v5.0.0 sources, > and I hope to update to the v6.0.0 sources very soon. > > Our target is VLIW with a lot of vectorisation support. Polly in theory > should be good for our platform, mainly because the transformations it > provides should eventually yield better ILP (more operations per > instruction). Previously I have tried Polly with limited benefits, and > almost all of the negatives were because the out-of-tree Polly was not > engaging TTI into its decision making, and I am very interested in > seeing what has been added to TTI for Polly that will allow me to tune > its behaviour.Dear Martin, I am very interested to hear use cases where Polly is not doing as well as it should. Polly uses TTI only to a very limited extend (e.g., to obtain cache-size knowledge). I expect the use of TTI to increase. Bug reports (especially performance bug reports), will be very helpful indeed. Best, Tobias> Looking forward to using Polly as a first-class citizen of LLVM, and > thanks for your huge work in this contribution. > > MartinO > > -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Tobias Grosser via llvm-dev > Sent: 15 January 2018 21:33 > To: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [llvm-dev] (no subject) > > Dear LLVM community, > > hope all of you had a good start into 2018 and a quiet branching of LLVM 6.0. > > With the latest LLVM release out of the way and a longer development > phase starting, we would like to restart the process of including Polly > and isl into core LLVM to bring changes in early on before the next LLVM > release. > > Short summary: > > * Today Polly is already part of each LLVM release (and will be > shipping with LLVM 6.0) for everybody to try, with conservative > defaults. > * We proposed to include Polly and isl into LLVM to provide modern > high-level loop optimizations into LLVM > * We suggested to develop Polly and isl as part of core LLVM to make > interactions with the core LLVM community easier and to allow us to > better integrate Polly with the new pass manager. > > Let me briefly summarize the current status: > > * Michael sent out an official email to discuss how to best include isl > into LLVM > (http://lists.llvm.org/pipermail/llvm-dev/2018-January/120408.html) > * We sent out the LLVM developers meeting notes > (_http://lists.llvm.org/pipermail/llvm-dev/2018-January/120419.html_) > * Philip Pfaffe prepared a preliminary patch set for integrating Polly > closer into LLVM: > > _https://github.com/pfaffe/llvm-project-20170507/commits/merge-polly-into-upstream_ > (further cleanup needed) > * We are working further with ARM (Florian Hahn and Francesco) to > upstream the inliner changes needed for the end-to-end optimization of > SPEC 2006 libquantum. _https://reviews.llvm.org/D38585_ > * Oleksandr, Sven and Manasij Mukherjee started to look into spatial > locality > * We worked on expanding the isl C++ bindings > (_http://repo.or.cz/isl.git/shortlog_). While a first set of patches is > already open, further patches will follow over the next couple of weeks. > > Let me briefly summarize the LLVM developer meeting comments on our > proposal (subjective summary) > > * Most people were interested in having polyhedral loop optimizations > being part of LLVM. > * Ideas of uses of isl beyond polyhedral loop scheduling were raised > (e.g., for polyhedral value analysis, dependence analysis, or broader > assumption tracking). Others were interested in the use of polyhedral > loop optimization with “learned” scheduling strategies. > * Specific concerns were raised that an integration of Polly into LLVM > may be an implicit choice of LLVMs loop optimization future. This is not > the case. While Polly is today the only end-to-end high-level loop > optimization, other approaches can and should explored (e.g., can there > be synergies with the region vectorizer?) > * How stable/fast/… is Polly today > * We build all of AOSP with rather restrictive compile-time limits > * Bootstrapping time of clang is regressed by 6% (at most) > * Removal of scalar dependences is today very generic and must be > sped up in the future > * Polly still shows up at the top of the middle-end, but larger > compile time regressions are often due to increased code size (and the > LLVM backend) > * We see non-trivial speedups for hmmer, libquantum, and various > linear-algebra kernels (we use gemm-specific optimizations). The first > two require additional flags to be enabled. > > The precise inclusion agenda has been presented here: > > http://lists.llvm.org/pipermail/llvm-dev/2017-September/117698.html > > After having merged communities, I suggest to form a loop optimization > working group which jointly discusses how LLVM’s loop optimizations > should evolve. > > I would like to invite comments regarding this proposal. > Are there any specific concerns we should address before requesting the > initial svn move? > > Best, > Tobias > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev