[LLVMdev] Vectorization: Next Steps

Tobias Grosser tobias at grosser.es
Mon Feb 6 15:47:32 PST 2012


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.



More information about the llvm-dev mailing list