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

[Chris Lattner via llvm-dev]

> On Jan 15, 2018, at 8:52 AM, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 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.

Hi Michael,

I have significant concerns about including ISL into LLVM.  LLVM intentionally takes a very conservative approach to bundling third party code with itself: we prefer instead of have them be external dependencies that are conditionally configured in on demand.

I’m not an expert in ISL in particular, but it looks like it is something of an odd dependency to include: it isn’t structured at all like LLVM, and it (apparently, I could definitely be wrong) depends on the GMP library which is LGPL.  Beyond licensing, it has an old-school C-style API which appears to be extremely inefficient compared to things like APInt that avoid allocations for 64-bit integers and less.

How much of ISL are you using?  What other options have you considered?  Why should this be included with every LLVM distribution instead of being conditionally compiled?  If the major issue is the polly regression tests, why not fix the tests?

-Chris