On Feb 6, 2012, at 1:56 PM, Hal Finkel wrote:>> If you do not want to use polly, you could use ISL >> http://freecode.com/projects/isl to set up the dependence problem and >> use ISL's ILP to solve it. > > isl is an LGPL project. It is not clear to me what the general consensus > would be on having a core analysis pass carry an LGPL dependency.This is fine for something that wants to live out of tree or be a secondary subproject, but isn't acceptable for something that wants to go into the mainline llvm repository and be a default part of the compiler. -Chris
On 02/06/2012 11:28 PM, Chris Lattner wrote:> On Feb 6, 2012, at 1:56 PM, Hal Finkel wrote: >>> If you do not want to use polly, you could use ISL >>> http://freecode.com/projects/isl to set up the dependence problem and >>> use ISL's ILP to solve it. >> >> isl is an LGPL project. It is not clear to me what the general consensus >> would be on having a core analysis pass carry an LGPL dependency. > > This is fine for something that wants to live out of tree or be a secondary subproject, but isn't acceptable for something that wants to go into the mainline llvm repository and be a default part of the compiler.If there is consensus that parts of Polly should be included in the core compiler, I am sure there are ways to solve these issues. Polly itself is BSD anyways, ISL and GMP are LGPL. As isl is using just a tiny subset of GMP I am pretty sure we can either rewrite this subset ourselves or extend the existing arbitrary (but fixed) width integer functionality in LLVM. This leaves us with ISL and CLooG. For both the copyright situation is pretty clear. The more complex library here is ISL. To my knowledge it is the only competitive open source integer set library. Rewriting it will be hard*. However, it was developed by one person (Sven Verdoolaege) and some smaller patches of me. AFAIK the copyrights are hold by the academic institutions he was working for. This means the copyright situation is clear. It cannot be changed overnight, but the institutions that need to be addressed are known. The main reason I did not look into this earlier is that I prioritized the development of Polly itself and I postponed copyright issues to the point where they actually need to be solved. This was not the case for Polly as a pure research project, but if parts of it may also be used in production that is obviously different. If there is a consensus that people want isl being used within core LLVM, I am very glad to investigate this further. (Otherwise it is still on my TODO list, but not highest priority). For now I must admit I am very comfortable having Polly as a side project, but I can also see that it might be useful to move more mature parts of it into LLVM. Cheers Tobi * Developing an equivalent library from scratch within LLVM will be at least as hard.
On Tue, 2012-02-07 at 00:47 +0100, Tobias Grosser wrote:> On 02/06/2012 11:28 PM, Chris Lattner wrote: > > On Feb 6, 2012, at 1:56 PM, Hal Finkel wrote: > >>> If you do not want to use polly, you could use ISL > >>> http://freecode.com/projects/isl to set up the dependence problem and > >>> use ISL's ILP to solve it. > >> > >> isl is an LGPL project. It is not clear to me what the general consensus > >> would be on having a core analysis pass carry an LGPL dependency. > > > > This is fine for something that wants to live out of tree or be a secondary subproject, but isn't acceptable for something that wants to go into the mainline llvm repository and be a default part of the compiler. > > If there is consensus that parts of Polly should be included in the core > compiler, I am sure there are ways to solve these issues. Polly itself > is BSD anyways, ISL and GMP are LGPL. As isl is using just a tiny subset > of GMP I am pretty sure we can either rewrite this subset ourselves or > extend the existing arbitrary (but fixed) width integer functionality in > LLVM. > > This leaves us with ISL and CLooG. For both the copyright situation is > pretty clear. The more complex library here is ISL. To my knowledge it > is the only competitive open source integer set library. Rewriting it > will be hard*. However, it was developed by one person (Sven > Verdoolaege) and some smaller patches of me. AFAIK the copyrights are > hold by the academic institutions he was working for. This means the > copyright situation is clear. It cannot be changed overnight, but the > institutions that need to be addressed are known.In my experience, it is better to investigate these kinds of things sooner rather than later. The more contributors a project acquires the harder it is to get the license changed. -Hal> > The main reason I did not look into this earlier is that I prioritized > the development of Polly itself and I postponed copyright issues to the > point where they actually need to be solved. This was not the case for > Polly as a pure research project, but if parts of it may also be used in > production that is obviously different. > > If there is a consensus that people want isl being used within core > LLVM, I am very glad to investigate this further. (Otherwise it is still > on my TODO list, but not highest priority). For now I must admit I am > very comfortable having Polly as a side project, but I can also see that > it might be useful to move more mature parts of it into LLVM. > > Cheers > Tobi > > * Developing an equivalent library from scratch within LLVM will be at > least as hard.-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory