[LLVMdev] Vectorization: Next Steps
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
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.
* Developing an equivalent library from scratch within LLVM will be at
least as hard.
More information about the llvm-dev