[LLVMdev] LLVM as a shared library

[Pete Cooper]

On Aug 6, 2014, at 12:00 AM, Nick Lewycky <nicholas at mxc.ca> wrote:

> Filip Pizlo 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.
> 
> They're already banned, so there isn't anything left to determine here, just code to fix.
Right, we’re *very* interested in fixing this code now, we just need to agree on the best solution before we start committing.
> 
>> 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.
> 
> Yes, for all these reasons. Two libraries may be using llvm under the hood unaware of each other, they can't both share global state. Command line flags block that. Our command-line tools should be parsing their own flags and setting state through some other mechanism, and that state musn't be more global than an LLVMContext.
In terms of "(1) Reduce or eliminate static initializers, global constructors, and global destructors”, the command line is the single biggest contributor to these.  I’d really like to get a conversation going about this specific issue and how we’ll solve it.

Just to kick things off, the majority of command line options are in files for passes, not all, but the majority.  I think we should move the command line options in to the passes themselves.  When the initialize method is called on a pass, it currently adds that passes name to the command line anyway (for opt to use).  I propose that passes be given the ability to register their command line options in initialize.

I haven’t yet worked out the cleanest way to do this.  There’s 2 options I think.  Either make some kind of command line registration available via the PassRegistry already passed to initialize, or we add another parameter to initialize which is the command line registry.

What do you think?

Thanks,
Pete

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