similar to: llvm-dev Digest, Vol 159, Issue 2

On Mon, Sep 4, 2017, at 20:49, Hal Finkel via llvm-dev wrote: > [tying to original thread] > > On 09/04/2017 01:37 PM, Adve, Vikram Sadanand via llvm-dev wrote: > > Hal, Tobias, et al. – > > > > I am strongly in favor of seeing a broader range of loop transformations, supported by strong dependence analysis, added to LLVM, and the Polly infrastructure seems to be by far

A completely non-technical point, but what's the current "polly" license? Does integrating that code conflict in any way with the work being done to relicense llvm? Does adding polly expose any additional legal risks? Some people from Reservoir labs have explicitly stated to me that some of their patents target polyhedral optimizations. You should almost certainly review their

On 09/11/2017 12:26 PM, Adam Nemet wrote: > Hi Hal, Tobias, Michael and others, > >> On Sep 1, 2017, at 11:47 AM, Hal Finkel via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> ** >> >> *Hi everyone,As you may know, stock LLVM does not provide the kind of >> advanced loop transformations

> On Sep 11, 2017, at 10:47 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 09/11/2017 12:26 PM, Adam Nemet wrote: >> Hi Hal, Tobias, Michael and others, >> >>> On Sep 1, 2017, at 11:47 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>>

** *Hi everyone,As you may know, stock LLVM does not provide the kind of advanced loop transformations necessary to provide good performance on many applications. LLVM's Polly project provides many of the required capabilities, including loop transformations such as fission, fusion, skewing, blocking/tiling, and interchange, all powered by state-of-the-art dependence analysis. Polly also

Hi Hal, Tobias, Michael, and others, I'd like to add my view (and a proposal) to this discussion and I apologize directly for doing this so late*. I also want to apologize because this email is long, contains various technical details and also argumentations that might need more justification. However, I am happy to provide further information (and/or examples) to explain my views if

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

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

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 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 run -polly-code-generator=cloog or -polly-code-generator=isl for code

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.

Hi Sebastian, thanks for the comments! On 09/27, Sebastian Pop wrote: > On Tue, Sep 26, 2017 at 2:00 AM, Tobias Grosser via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On Tue, Sep 26, 2017, at 00:03, Johannes Doerfert wrote: > >> It depends on what you want. If you want a polyhedral scheduler right > >> away, integration is the way to go. > > I

On Wed, Jan 17, 2018, at 07:22, Chris Lattner via llvm-dev wrote: > > On Jan 15, 2018, at 8:52 AM, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As for the main motivation on why to import the entire source of isl at all: > > Polly interacts relative tightly with isl which provide the main > > optimization algorithms. For instance, Polly's

At 2013-09-09 05:02:14,"Tobias Grosser" <tobias at grosser.es> wrote: >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

Hi, Johannes, Thanks for writing this. I certainly think you have the right idea in terms of the desired end state and modular design. On 09/19/2017 07:33 PM, Johannes Doerfert wrote: > Hi Hal, Tobias, Michael, and others, > > I'd like to add my view (and a proposal) to this discussion and I > apologize directly for doing this so late*. I also want to apologize > because this

Hi Hal, On 09/22, Hal Finkel wrote: > Hi, Johannes, > > Thanks for writing this. I certainly think you have the right idea in terms > of the desired end state and modular design. Thanks for the feedback! > On 09/19/2017 07:33 PM, Johannes Doerfert wrote: > >Hi Hal, Tobias, Michael, and others, > > > >I'd like to add my view (and a proposal) to this

On 09/22/2017 12:03 AM, Mehdi AMINI wrote: > Hi Hal, > > > 2017-09-21 20:59 GMT-07:00 Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: > > > On 09/12/2017 10:26 PM, Gerolf Hoflehner wrote: >> >> >>> On Sep 11, 2017, at 10:47 PM, Hal Finkel via llvm-dev >>> <llvm-dev at

Hi Hal, 2017-09-21 20:59 GMT-07:00 Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> : > > On 09/12/2017 10:26 PM, Gerolf Hoflehner wrote: > > > > On Sep 11, 2017, at 10:47 PM, Hal Finkel via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > On 09/11/2017 12:26 PM, Adam Nemet wrote: > > Hi Hal, Tobias, Michael and others, > *...* >