[LLVMdev] LLVM as a shared library

[Philip Reames]

On 08/05/2014 12:38 PM, Chris Bieneman wrote:
> Hello LLVM community,
>
> Over the last few years the LLVM team here at Apple and development teams elsewhere have been busily working on finding new and interesting uses for LLVM. Some of these uses are traditional compilers, but a growing number of them aren’t. Some of LLVM’s new clients, like WebKit, are embedding LLVM into existing applications. These embedded uses of LLVM have their own unique challenges.
>
> Over the next few months, a few of us at Apple are going to be working on tackling a few new problems that we would like solved in open source so other projects can benefit from them. Some of these efforts will be non-trivial, so we’d like to start a few discussions over the next few weeks.
>
> Our primary goals are to (1) make it easier to embed LLVM into external projects as a shared library, and (2) generally improve the performance of LLVM as a shared library.
>
> The list of the problems we’re currently planning to tackle is:
>
> (1) Reduce or eliminate static initializers, global constructors, and global destructors
> (2) Clean up cross compiling in the CMake build system
> (3) Update LLVM debugging mechanisms for being part of a dynamic library
> (4) Move overridden sys calls (like abort) into the tools, rather than the libraries
> (5) Update TableGen to support stripping unused content (i.e. Intrinsics for backends you’re not building)
>
> We will be sending more specific proposals and patches for each of the changes listed above starting this week. If you’re interested in these problems and their solutions, please speak up and help us develop a solution that will work for your needs and ours.
>
> Thanks,
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
I'm very happy to see this effort happening.  I also maintain an our of 
tree frontend and deal with these issues on a semi-regular basis.

Worth noting is that we do not use the C interface and have little 
interesting in ever doing so.  We've chosen to accept the version lock 
as a necessary evil - mostly because we need enough internal changes to 
LLVM we'd be stuck with it anyway.  I'm mostly just pointing this out 
for the purpose of contrast with other responders on the thread.

I would honestly love to see a slightly more stable C++ interface, but 
I've mostly accepted that's not going to happen.  I'm not even talking 
stability from release to release; I'd be thrilled with depreciation 
periods in terms of days or weeks.  We're generally fairly in sync with 
ToT, but even with that, we face a lot of breaking changes.  There's a 
general assumption that only llvm subprojects need to be migrated, and 
as soon as that's complete, old APIs are removed.  Simply having a 
slightly longer period to do our own migrations would be immensely helpful.

Philip