similar to: Inclusion of Polly and isl into core LLVM

On Mon, 15 Jan 2018 22:44:45 +0100, Tobias Grosser via llvm-dev wrote: <snip> > * 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

On Tue, 23 Jan 2018 01:23:51 +0000, Alex Elsayed via llvm-dev wrote: > On Mon, 15 Jan 2018 22:44:45 +0100, Tobias Grosser via llvm-dev wrote: > > <snip> > >> * 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

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

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

Hi, Nadav, Chris, et al., If you've not already seen it, we had a long discussion about incorporating Polly into LLVM on llvm-dev, http://lists.llvm.org/pipermail/llvm-dev/2017-September/117063.html (with a continuation in October: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118125.html) with a lot of detailed information. I think it is important, first, that we agree on the goals

Hi Tobi,  I have some concerns about adding Polly into LLVM proper. I think that it's great that Polly is a part of the LLVM umbrella of projects, like Clang and LLDB. However, I am not convinced that Polly belongs in the LLVM compiler library. LLVM is a major dependency for so many external projects. Rust, Swift, GPU drivers by different vendors, and JIT compilers all rely on LLVM. Projects

Hi Hal,  Thanks for the very detailed email. I followed the ongoing discussion about moving ISL and Polly from a subproject of LLVM into the LLVM library. I was not convinced by the arguments in the threads. I believe that the potential benefits of the change that you are trying to make are not proportional to the high cost for the rest of the users of the compiler library. Traditional compiler

On Wed, Nov 20, 2013 at 05:00:44PM +0100, Tobias Grosser wrote: > On 11/20/2013 04:50 PM, Jack Howarth wrote: >> On Tue, Nov 19, 2013 at 12:07:18PM +0100, Tobias Grosser wrote: >>> On 11/19/2013 08:50 PM, Jack Howarth wrote: >>>> Tobias, >>>> Can we add something like the following to polly 3.4? >>>> >>>> Index: CMakeLists.txt

Tobias, Can we add something like the following to polly 3.4? Index: CMakeLists.txt =================================================================== --- CMakeLists.txt (revision 195142) +++ CMakeLists.txt (working copy) @@ -81,9 +81,14 @@ set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PAT FIND_PACKAGE(Isl REQUIRED) FIND_PACKAGE(Gmp REQUIRED) -FIND_PACKAGE(Cloog) FIND_PACKAGE(Pluto)

On Sun, Feb 10, 2013 at 09:23:59AM -0500, Jack Howarth wrote: > Tobi, > What is the situation with -polly-codegen-isl in polly svn? Should we be testing > polly without cloog as the default configuration or will cloog use not be deprecated > in 3.3? > Jack Tobi, Is it even possible to build polly without cloog at the moment or is the presence of the -polly-codegen-isl

On 11/20/2013 04:50 PM, Jack Howarth wrote: > On Tue, Nov 19, 2013 at 12:07:18PM +0100, Tobias Grosser wrote: >> On 11/19/2013 08:50 PM, Jack Howarth wrote: >>> Tobias, >>> Can we add something like the following to polly 3.4? >>> >>> Index: CMakeLists.txt >>> ===================================================================

On 11/19/2013 08:50 PM, Jack Howarth wrote: > Tobias, > Can we add something like the following to polly 3.4? > > Index: CMakeLists.txt > =================================================================== > --- CMakeLists.txt (revision 195142) > +++ CMakeLists.txt (working copy) > @@ -81,9 +81,14 @@ set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PAT > > FIND_PACKAGE(Isl

On Tue, Nov 19, 2013 at 12:07:18PM +0100, Tobias Grosser wrote: > On 11/19/2013 08:50 PM, Jack Howarth wrote: >> Tobias, >> Can we add something like the following to polly 3.4? >> >> Index: CMakeLists.txt >> =================================================================== >> --- CMakeLists.txt (revision 195142) >> +++ CMakeLists.txt (working

On 04/26/2013 05:08 AM, tanmx_star wrote: > Hi all, Hi, thanks for the update and sorry for the delay in reviewing. I just had a look at your proposal. > I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project!

Tobi, What is the situation with -polly-codegen-isl in polly svn? Should we be testing polly without cloog as the default configuration or will cloog use not be deprecated in 3.3? Jack

On 09/01/2013 08:02 PM, Star Tan wrote: > Hi all, > > > It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc. Some basic evaluation and analysis for Polly's code generation can be referred to http://llvm.org/bugs/show_bug.cgi?id=16898. > > > Currently, we can choose to

Hello all, The performance comparison between Polly's Cloog and ISL code generator is posted on http://188.40.87.11:8000/db_default/v4/nts/59?compare_to=58&baseline=58 It seems their execution-time performance are comparable: Performance Regressions - Execution Time  (ISL over Cloog) MultiSource/Benchmarks/TSVC/ControlFlow-flt/ControlFlow-flt 8.49%

At 2013-09-02 17:05:52,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/01/2013 08:02 PM, Star Tan wrote: >> Hi all, >> >> >> It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc. Some basic evaluation and analysis for Polly's code generation

Hi, On Thu, Sep 28, 2017 at 6:15 PM, Johannes Doerfert via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Actually, I started to copy parts of the ScalarEvolution interface in > order to integrate the analysis passes this way into LLVM > transformations. While it is obviously hard (and probably not useful) to > provide "exactly" the same interface as

On 09/08/2013 11:46 AM, Star Tan wrote: > At 2013-09-02 17:05:52,"Tobias Grosser" <tobias at grosser.es> wrote: > >> On 09/01/2013 08:02 PM, Star Tan wrote: >>> Hi all, >>> >>> >>> It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc.