[llvm-dev] RFC: Import of Integer Set Library into LLVM source tree

[Tobias Grosser via llvm-dev]

On Wed, Jan 17, 2018, at 01:41, Philip Reames via llvm-dev wrote:
> 
> 
> On 01/15/2018 08:52 AM, Michael Kruse via llvm-dev wrote:
> > Dear community,
> >
> > for our goal to make polyhedral optimization available in the main
> > LLVM source, we will need the Integer Set Library (isl)[1]. It is the
> > main dependency of Polly, but would be required even if we do not
> > directly import Polly.
> >
> > I already prepared a patch [2], unfortunately without feedback on the
> > general approach. As Philip suggested in the review, I am reaching out
> > with an RFC with a wider audience on llvm-dev.
> >
> > As for the main motivation on why to import the entire source of isl at all:
> > Polly interacts relative tightly with isl which provide the main
> > optimization algorithms. For instance, Polly's regression tests
> > compare the string output of set representation, which unfortunately
> > can change between versions. For instance, if a newer version
> > implements a simpler string description of the same set. That means
> > that tests would fail if a different version is installed on the host
> > system. This is significant for buildbots that would need regular
> > manual action to install a newer version of isl on the system.
> >
> > An alternative would be to only store the git sha1 and a CMake script
> > would download that version when building. However, it would also be
> > more difficult to both sources in-sync in the checkout (think of git
> > bisect).
> >
> > I suppose these were also the reasons why Polly imported the isl
> > source in commit r228193 instead of requiring users to call
> > utils/checkout_isl.sh manually.
> >
> >
> > The other design decisions and rationales are mentioned in the review
> > summary [2]. I repeat them here so they can be referred to in replies.
> >
> > * The library is named LLVMISL and contained in the lib/ISL folder to
> > work best with LLVM's component system. The component's name "ISL" was
> > chosen over "isl" as it matches the capitalization of other
> > two/three-letter-acronym components.
> >
> > * Isl's headers are installed into $PREFIX/include/llvm/ISL/isl. This
> > is to not conflict with potentially user/system-installed isl headers.
> > Please note that this means that MIT-licensed headers land on the
> > target system.
> This comment caught my eye.  Looking at ISL, it appears to offer a MIT 
> license only.  How does this interact with LLVM's licensing? There does 
> appear to be some precedent for third party libraries under different 
> licenses, but this needs careful discussion and review by a 
> knowledgeable party.  (I am not one.)

We changed the license of isl to MIT following the recommendation of Chris Lattner. a while ago. Hal Finkel recently re-checked the license situation. It seems to be fine for now. If at some point this is becoming a blocker, we could theoretically consider re-licensing once more (or alternatively rewrite parts of isl with the knowledge we gained from using it).

Best,
Tobias