similar to: [RFC] Polly Status and Integration

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

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

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

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

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

Dear all, please find below the meeting notes form the Polly BoF (as taken by Michael Kruse). Comments and feedback is very much appreciated. Best, Tobias Status update * Polly late in pipeline * Uses TargetTransformInfo * Part of the release process * isl: C++ interface, MIT licenced, improved scheduler * Polly integration plan; result: isl and Polly available in each build * Better

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

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 our best bet to make that happen. I have a couple of questions: 1) Integer constraint libraries like ISL (and Omega, which I used extensively in a previous project) are fundamentally solving

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

[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

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

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

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

On Wed, Sep 13, 2017 at 8:05 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 09/13/2017 06:53 AM, C Bergström wrote: > > > > On Wed, Sep 13, 2017 at 7:43 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> On 09/13/2017 02:16 AM, C Bergström wrote: >> >> A completely non-technical point, but what's the current "polly"