similar to: Meeting notes Polly BoF

[add 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

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

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

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

Hi Sjoerd, On 09/20, Sjoerd Meijer wrote: > I have not been following the polyhedral developments in both GCC and > LLVM very closely the last few years, but I was just wondering if > there are any lessons learned we should look at (or actually already > aware of) in GCC's implementation and integration of Graphite. For > example, do we know if it is (still) enabled/used/etc.?

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, 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 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

On 09/28, Alexandre Isoard wrote: > Polly is oriented towards providing a full blown polyhedral compiler > pipeline, this is great in the sense that it allows to do all the high > level transformations we can dream of, but this is also difficult to > compose with current LLVM passes, we lose debug information, and it is > relatively hard to control what happen. As such, it might be

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

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 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 think this is the topic of the thread as the folks who started this discussion stated that they want to see

On Tue, Sep 26, 2017, at 00:03, Johannes Doerfert wrote: > 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: >

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 Mon, Sep 4, 2017, at 22:14, Adve, Vikram Sadanand wrote: > Responses inline, marked with (***VSA***) because Outlook on a Mac sucks > for inline replies! > > > On 9/4/17, 2:14 PM, "Tobias Grosser" <tobias.grosser at inf.ethz.ch> wrote: > > On Mon, Sep 4, 2017, at 20:49, Hal Finkel via llvm-dev wrote: > > [tying to original thread] >

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 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 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!

> 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: >>> >>>

Michael, [Sorry that I don't have you in To:. I don't have your addr that I can use since I'm replying through digest.] I'm also sorry that I'm not commenting on the main part of your RFC in this reply. I just want to focus on one thing here. Proposed Loop Optimization Framework ------------------------------------