[llvm-dev] (no subject)

[Tobias Grosser via 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