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

[Michael Kruse via llvm-dev]

2018-01-19 15:56 GMT+01:00 Joerg Sonnenberger via llvm-dev
<llvm-dev at lists.llvm.org>:
> On Mon, Jan 15, 2018 at 05:52:02PM +0100, Michael Kruse via llvm-dev wrote:
>> * 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.
>
> Are the ISL sources themselve put into a namespace under llvm? That's my
> primary concern: a program wanting to use a random ISL version and LLVM
> at the same time.

No, isl and its headers are written in plain C and we do not modify
its sources to put symbols into namespaces (and compile as C++
sources).

We actually had this occurring with Draggonegg: isl would be used by
both LLVM/Polly and GCC/Graphite and loaded into the same address
space. We solved this by hiding the isl symbols with
-fvisibility=hidden. We do not do this anymore because it makes
BUILD_SHARED_LIBS=ON/OFF behave differently, and Draggenegg being
de-facto deprecated.

Since isl includes imath, it uses a different approach: The file
"wrap.h" #defines every imath symbol with an "isl_" prefix, e.g.
#define impq_cmp isl_impq_cmp

We could modify the source and append/prepend namespaces around the
C-sources. The isl-merge.py script would merge them into upstream
sources and only conflict when the start/end of the file is changed
upstream, and then easy to resolve. Or one compiles such as
isl_ctx.cpp:

namspace llvm {
#include "isl_ctx.c"
}

The isl source are currently not C++-friendly because of implicit
casts from void*, but this can be upstreamed to isl. We might even try
upstream a preprocessor definition to optional use namespaces:

#ifdef ISL_NAMESSPACE
namespace ISL_NAMESSPACE {
#endif

What I want to say, if this should be a major issue, there are solutions for it.

Michael