[LLVMdev] LLVM as a shared library

[Filip Pizlo]

> On Aug 5, 2014, at 4:02 PM, Josh Klontz <josh.klontz at gmail.com> wrote:
> 
> Filip,
> 
> As a non-WebKit embedder currently using the C++ API (www.liblikely.org), here are my thoughts:
> - Perhaps the only reason I'm using the C++ API instead of the C API is that the Kaleidoscope tutorial is written against the C++ API. That's where I started, and momentum has prevented me from switching. It may make sense to re-write this tutorial using the C API if we want to encourage new developers to default to this interface.

That’s a great point!  It would be awesome to have this.  I remember that when I started working on WebKit’s FTL JIT I had to sort of mentally translate a lot of examples written against the C++ API.  It wasn’t easy at first.

> - Based on the (excellent) documentation online and a close following of this mailing list, I haven't been convinced that the C API is really given first class support in LLVM. Perhaps this is just an issue of advertising better, but it makes me hesitant to change.

It’s first-class enough that WebKit has been using it for months now.  WebKit is a fairly big project and there is overlap between LLVM and WebKit contributors.  In practice this means that the C API doesn’t break often and when it does, it gets fixed.

> - I run into enough minor bugs that my project ends up tracking the master branch pretty closely. As such, I don't think I'll get away from static builds in the near future. Being unable to switch to shared-library-tagged-releases disincentives the API switch.

We track master as well, because we also often find bugs.  Using the C API means makes this easier.  With the C++ API you risk having to change stuff on your end because something in the C++ API changed to support some LLVM refactoring.  With the C API we almost never have this problem.

> - A barebones transition guide hosted with the rest of the LLVM docs could lower the activation energy needed to switch.

Good point!

> 
> Hope that helps!

It does, thanks!

> 
> v/r,
> Josh
> 
> 
> On Tue, Aug 5, 2014 at 4:17 PM, Filip Pizlo <fpizlo at apple.com> wrote:
> This is exciting!
> 
> I would be happy to help.
> 
> 
> > On Aug 5, 2014, at 12:38 PM, Chris Bieneman <beanz at apple.com> 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)
> 
> Also:
> 
> (6) Determine if command line options are the best way of passing configuration settings into LLVM.
> 
> It’s an awkward abstraction when LLVM is embedded. I suspect (6) will be closely related to (1) since command line option parsing was the hardest impediment to getting rid of static initializers.
> 
> My understanding of the shared library proposal is that the library only exposes the C API since the C++ API is not intended to allow for binary compatibility.  So, I think we need to either add the following as either an explicit goal of the shared library work, or as a closely related project:
> 
> (7) Make the C API truly great.
> 
> I think it’s harmful to LLVM in the long run if external embedders use the C++ API.  I think that one way of ensuring that they don’t have an excuse to do it is to flesh out some things:
> 
> - Add more tests of the C API to ensure that people don’t break it accidentally and to give more gravitas to the C API backwards compatibility claims.
> - Increase C API coverage.
>         - For example, WebKit currently sidesteps the C API to pass some commandline options to LLVM.  We don’t want that.
>         - Add more support for reasoning about targets and triples.  WebKit still has to hardcode triples in some places even though it only ever does in-process JITing where host==target.  That’s weird.
>         - Expose debugging and runtime stuff and make sure that there’s a coherent integration story with the MCJIT C API.
>                 - Currently it’s difficult to round-trip debug info: creating it in C is awkward and parsing DWARF sections that MCJIT generates involves lots of weirdness.  WebKit has its own DWARF parser for this, which shouldn’t be necessary.
>                 - WebKit is about to have its own copies of both a compactunwind and EH frame parser.  The contributor who “wrote” the EH frame parser actually just took it from LLVM.  The licenses are compatible, but nonetheless, copy-paste from LLVM into WebKit should be discouraged.
> - Engage with non-WebKit embedders that currently use the C++ API to figure out what it would take to get them to switch to the C API.
> 
> I think that a lot of time when C API discussions arise, lots of embedders give excuses for using the C++ API.  WebKit used the C API for generating IR and even doing some IR manipulation, and for driving the MCJIT.  It’s been a positive experience and we enjoy the binary compatibility that it gives us.  I think it would be great to see if other embedders can do the same.
> 
> -Filip
> 
> >
> > 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
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140805/7cae87c0/attachment.html>