C Bergström via llvm-dev
2017-Sep-13 12:30 UTC
[llvm-dev] [RFC] Polly Status and Integration
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" license? >> Does integrating that code conflict in any way with the work being done to >> relicense llvm? >> >> >> Good question. I discussed this explicitly with Tobias, and his general >> feeling is that relicensing isl again would be doable if necessary (we >> already did this once, to an MIT license, in order to enable better LLVM >> integration). >> >> >> 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 >> portfolio or contact them. >> >> If at some point someone wants to add real loop optimizations - will >> there be a conflict? >> >> >> Can you define "real loop optimizations"? >> > > I think most readers here will understand what I mean. I can go find > specific chapters of textbooks if it's unclear. Maybe the word "real" could > be replaced with traditional, well tested, industry standard or something > else. (ok I'll stop being snarky) > > > That's what I thought you meant. No, I believe there's not a conflict. In > fact, this will provide infrastructure to make this easier. While you can > handle a bunch of these as one problem using this kind of framework, you > don't need to do so. >By this I think you either mean A) the polly stuff will provide a better analysis pass or B) the llvm side will have a better analysis pass, correct? If you mean A, then that's cool. I was unaware that poly had an interface and could be used like this. The cost model aspect is very important. I'm mildly curious how it builds this. (correct me if I'm wrong please) It's my lay understanding that poly optimizations are an either or and do not generally play well with tradtional methods. More specifically, after poly things are "messed up" and it would be difficult to do another (traditional type) transformation that it missed. Since llvm doesn't have or doesn't do the traditional side very well, this is less a concern though. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170913/f39f09e4/attachment.html>
Hal Finkel via llvm-dev
2017-Sep-15 04:04 UTC
[llvm-dev] [RFC] Polly Status and Integration
On 09/13/2017 07:30 AM, C Bergström wrote:> > On Wed, Sep 13, 2017 at 8:05 PM, Hal Finkel <hfinkel at anl.gov > <mailto: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 >> <mailto: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" license? Does integrating that code conflict in any >>> way with the work being done to relicense llvm? >> >> Good question. I discussed this explicitly with Tobias, and >> his general feeling is that relicensing isl again would be >> doable if necessary (we already did this once, to an MIT >> license, in order to enable better LLVM integration). >> >>> >>> 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 portfolio or contact them. >>> >>> If at some point someone wants to add real loop >>> optimizations - will there be a conflict? >> >> Can you define "real loop optimizations"? >> >> >> I think most readers here will understand what I mean. I can go >> find specific chapters of textbooks if it's unclear. Maybe the >> word "real" could be replaced with traditional, well tested, >> industry standard or something else. (ok I'll stop being snarky) > > That's what I thought you meant. No, I believe there's not a > conflict. In fact, this will provide infrastructure to make this > easier. While you can handle a bunch of these as one problem using > this kind of framework, you don't need to do so. > > > > By this I think you either mean A) the polly stuff will provide a > better analysis pass or B) the llvm side will have a better analysis > pass, correct? > > If you mean A, then that's cool. I was unaware that poly had an > interface and could be used like this.It does now (I believe that it was developed as part of a GSoC project last year: http://llvm.org/svn/llvm-project/polly/trunk/include/polly/DependenceInfo.h).> The cost model aspect is very important. I'm mildly curious how it > builds this. > > (correct me if I'm wrong please) It's my lay understanding that poly > optimizations are an either or and do not generally play well with > tradtional methods. More specifically, after poly things are "messed > up" and it would be difficult to do another (traditional type) > transformation that it missed.Polly doesn't really use this currently, but isl has an incremental scheduling interface, and other ways to guide the transformation process, so it should be possible to build passes that use the infrastructure to do a restricted subset of transformations. In short, it can do a bunch of stuff at the same time, but doesn't have to be used that way. As such, you can actually use Polly's infrastructure to build many of these individual classical transformations (in what I believe is a relatively-simply way - although take this with a grain of salt because I don't know how much this has been tried in practice). -Hal> Since llvm doesn't have or doesn't do the traditional side very well, > this is less a concern though. > >-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170914/28ba4737/attachment.html>
C Bergström via llvm-dev
2017-Sep-15 04:27 UTC
[llvm-dev] [RFC] Polly Status and Integration
On Fri, Sep 15, 2017 at 12:04 PM, Hal Finkel <hfinkel at anl.gov> wrote:> > On 09/13/2017 07:30 AM, C Bergström wrote: > > > 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" >>> license? Does integrating that code conflict in any way with the work being >>> done to relicense llvm? >>> >>> >>> Good question. I discussed this explicitly with Tobias, and his general >>> feeling is that relicensing isl again would be doable if necessary (we >>> already did this once, to an MIT license, in order to enable better LLVM >>> integration). >>> >>> >>> 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 >>> portfolio or contact them. >>> >>> If at some point someone wants to add real loop optimizations - will >>> there be a conflict? >>> >>> >>> Can you define "real loop optimizations"? >>> >> >> I think most readers here will understand what I mean. I can go find >> specific chapters of textbooks if it's unclear. Maybe the word "real" could >> be replaced with traditional, well tested, industry standard or something >> else. (ok I'll stop being snarky) >> >> >> That's what I thought you meant. No, I believe there's not a conflict. In >> fact, this will provide infrastructure to make this easier. While you can >> handle a bunch of these as one problem using this kind of framework, you >> don't need to do so. >> > > > By this I think you either mean A) the polly stuff will provide a better > analysis pass or B) the llvm side will have a better analysis pass, correct? > > If you mean A, then that's cool. I was unaware that poly had an interface > and could be used like this. > > > It does now (I believe that it was developed as part of a GSoC project > last year: http://llvm.org/svn/llvm-project/polly/trunk/include/ > polly/DependenceInfo.h). > > The cost model aspect is very important. I'm mildly curious how it builds > this. > > (correct me if I'm wrong please) It's my lay understanding that poly > optimizations are an either or and do not generally play well with > tradtional methods. More specifically, after poly things are "messed up" > and it would be difficult to do another (traditional type) transformation > that it missed. > > > Polly doesn't really use this currently, but isl has an incremental > scheduling interface, and other ways to guide the transformation process, > so it should be possible to build passes that use the infrastructure to do > a restricted subset of transformations. In short, it can do a bunch of > stuff at the same time, but doesn't have to be used that way. As such, you > can actually use Polly's infrastructure to build many of these individual > classical transformations (in what I believe is a relatively-simply way - > although take this with a grain of salt because I don't know how much this > has been tried in practice). >Thanks for your replies. I remember talking with a researcher, I can't remember who, but one of the side effect upsides to this may be that "loop transformations" end up being handled in a way that's closer to optimal. Most compilers, at least the ones I have worked on, will perform loop optimizations and analysis on a whole PU or TU. By feeding polly smaller pieces (regions?) you'll allow it to do a more accurate job as well as not have hueristics which are good for loop, but bad for maybe some other scalar code impacted. The closest work-around I have to this was outlining the region/kernel into it's own PU, doing everthing needed and then very late in the compilation phase "inlining" it again. I'm curious how this all turns out.. good luck -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170915/ba2da37d/attachment.html>