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
Sounds reasonable. Do you have any plans or interest in annotating adding visibility / export attributes to the API? I'm trying to gauge demand for them. On Tue, 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) > > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140805/d6ed7729/attachment.html>
(adding Juergen and Pete who will be working on this with me) We haven’t fully fleshed out the exact implementation yet. Our target user for the initial work is WebKit. For WebKit we want to generate a shared library which only exports the C API. We were discussing doing this with an exports list for the linker, but visibility annotations is another option. -Chris> On Aug 5, 2014, at 12:56 PM, Reid Kleckner <rnk at google.com> wrote: > > Sounds reasonable. > > Do you have any plans or interest in annotating adding visibility / export attributes to the API? I'm trying to gauge demand for them. > > On Tue, 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) > > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140805/5142c5f9/attachment.html>
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
On 5 August 2014 20:38, Chris Bieneman <beanz at apple.com> wrote:> (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)One other thing that I'd like to see is a common framework for defining, describing and inferring architectural support. Tools use a lot of string parsing and, as Filip said, command line options don't normally mean the exact same thing across tools. So that the same arch/cpu/fpu/abi/target options will be parsed identically across all tools (and external users) and mean exactly the same thing to the back-end, when building a new sub-target, it should only accept a TargetDescription object or whatever holds all the options. cheers, --renato
On Tue, Aug 05, 2014 at 12:38:49PM -0700, 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. >This sounds great.> 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 systemOne problem we have with the Mesa project is that the automake and CMake build system produce different shared libraries. Automake builds libLLVM-major.minor.so while CMake builds a different shared library for each component: e.g. libLLVMSupport.so To cope with this, Mesa's build system has to try to guess which build system was used in order to find the libraries. Do you have plans to standardize the shared libraries produced by LLVM's build systems? Even better, will improving cross compiling in the CMake build system make it possible to completely drop automake? -Tom> (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
> (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. >Honestly I think if you want to make the C API great we should burn it to the ground and come up with another one - and one that can be versioned as well so we don't have the problems of being limited in what we can do to llvm by needing compatibility with the C API. -eric
> On Aug 5, 2014, at 1:33 PM, Tom Stellard <tom at stellard.net> wrote: > > On Tue, Aug 05, 2014 at 12:38:49PM -0700, 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. >> > > This sounds great. > >> 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 > > One problem we have with the Mesa project is that the automake and CMake build > system produce different shared libraries. Automake builds libLLVM-major.minor.so > while CMake builds a different shared library for each component: e.g. libLLVMSupport.so > > To cope with this, Mesa's build system has to try to guess which build system > was used in order to find the libraries. > > Do you have plans to standardize the shared libraries produced by LLVM's build systems?We had not planned to standardize the build systems, but it is interesting to consider. IMHO, maintaining two build systems is a royal pain.> > Even better, will improving cross compiling in the CMake build system make > it possible to completely drop automake?I would really like to think so, but there will be quite a bit of work involved in getting everyone using the Automake build system to migrate off. One snag with getting off automake that I’m aware of is compiler-rt. I haven’t been able to make sense of the compiler-rt CMake configs well enough to come up with a good solution for cross-compiling. -Chris> > -Tom > >> (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
On Tue, Aug 05, 2014 at 01:17:27PM -0700, 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. > > 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.Just to give a bit of perspective from another external LLVM client: GoLLVM [1], the LLVM bindings for Go used by the llgo compiler [2], mostly uses the C bindings, but it does need to resort to the C++ API (with its own set of C bindings) for a few things: Exporting bitcode to memory buffer: https://github.com/go-llvm/llvm/blob/master/bitwriter.cpp Use of attribute masks above 1 << 31: https://github.com/go-llvm/llvm/blob/master/core.cpp Debug info generation: https://github.com/go-llvm/llvm/blob/master/dibuilder.cpp Loading plugins and setting flags: https://github.com/go-llvm/llvm/blob/master/support.cpp Adding instrumentation passes: https://github.com/go-llvm/llvm/blob/master/transforms_instrumentation.cpp I think most of this could be upstreamable in some shape or form, but I heard from debug info experts a few months ago that the IR format was unstable, so the solution we went with was to wrap the C++ API so that we would be notified (by the compiler) when the format changes, rather than creating debug info directly and having it potentially silently discarded. I'm not sure if the debug info situation has changed since then. The plugin/flags stuff is valuable to external projects for exactly the same reasons that Clang supports plugins and LLVM flags. I don't see any reason to make the specific flag semantics stable, and we can document this as such. Thanks, -- Peter [1] https://github.com/go-llvm/llvm [2] https://github.com/go-llvm/llgo
Hi Chris,> 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.That sounds great. Just as a note, using LLVM libraries for external projects using CMake was recently improved [1] (mostly by Brad King). I've never built LLVM as a single shared library (I'm not aware of there being a CMake option to do so) using CMake but it would be great if doing this didn't create any problems for users of this interface. If you'd like me to take a look at anything related to this, please let me know.> (2) Clean up cross compiling in the CMake build systemBrad King might be interested in this so it might be a good idea to CC him in any patches related to this. [1] http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project Thanks, Dan.
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. - 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. - 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. - A barebones transition guide hosted with the rest of the LLVM docs could lower the activation energy needed to switch. Hope that helps! 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/acd94d02/attachment.html>
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.> 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.> 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.The quality with which we maintain the C API today suggests that we collectively think of it as an albatross to be suffered. There is work necessary to change that perception too. 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.Yes, for well-designed high level APIs like libLTO and libIndex. For other APIs, we should remove the backwards compatibility guarantees ...> - Increase C API coverage.... which in turn allows us to do this. Designing a good high-level API is hard (even libLTO has very ugly cracks in its API surface) and that makes it hard to do. What actually happens is that people write C APIs that closely match the C++ APIs in order to access them through other languages, but there's no way we can guarantee compatibility without freezing the C++ API too. Which we never will. This isn't a theoretical problem either, look at this case: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140804/229354.html where we made a straight-forward update to the LLVM IR, but in theory a user of the C API would be able to observe the difference, and that could in turn break a C API user that was relying on the way old LLVM worked. The solution is to offer two levels of C API, one intended for people to use to bind to their own language. This matches the C++ API closely and changes when the C++ API changes. (It could even be partially/wholy auto-generated via a clang tool?) Users of it will be broken with newer versions. Secondly, some people really want a stable interface, so we give them an API expressed in higher-level tasks they want to achieve, so that we can change the underlying workings of how LLVM works without disturbing the API. That can be made ABI stable.> - For example, WebKit currently sidesteps the C API to pass some commandline options to LLVM. We don’t want that.Seconded!> - 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.Sounds good.> - 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.I am not familiar with the MCJIT C API, but this sounds reasonable. I'll trust that you know what you're doing.> - 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.Engage with our users? That's crazy talk! ;) Nick> 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
On 5 Aug 2014, at 21:17, Filip Pizlo <fpizlo at apple.com> wrote:> - 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 maintain a reasonable amount of out-of-tree code that embeds LLVM in various things, including a couple of language front ends, an out-of-tree back end, and some tools for interfacing with experimental hardare and so suffer the pain of C++ API changes on a fairly frequent basis. The C APIs generally feel clunky to use. If we have a stable C API that is useful, I'd love to see C++ wrappers so that we don't have to suffer things like iterators. Currently, we conflate 'C' and 'stable'. In many cases, I'd prefer a C++ API to a C one, or would be happy to write (or even use automatically generated) thin C wrappers around C++. The requirement is not the language, it's the stability. I presume this also applies to WebKit: there's no reason why a C++ library should prefer a C API for talking to a C++ library. Stability isn't just a binary thing. We care about several different definitions: - ABI doesn't change. I can keep using the same binary with new LLVM shared libraries. Symbols are versioned and new code can just use the new version. - API doesn't change. I have to recompile, but there are SOVERSION bumps whenever I need to and so the version that I need can easily coexist on the same system with newer ones until I get around to recompiling. - API doesn't change gratuitously. Public APIs change, but only after a deprecation period and not simply to please some developer's aesthetic. We don't randomly rename classes or change capitalisation of functions without at least shipping one release with both the new and old versions working and being marked as deprecated. Most of LLVM fails even to meet the third requirement. For most of the code that I maintain, I have no strong requirements for the first, would be very happy with the second, and would find the third acceptable. Some things clearly can't be supported by a set-in-stone interface. Much as I'd love for out-of-tree back ends to be something that people could just ship as plugins, it's not really feasible. There are lots of things in the back end interface that need fixing, and having to support an interface that's defined before they're fixed would be a lot of pain. I also don't see a benefit in exporting these A few of the things that I maintain out of tree are optimisations. We've added some infrastructure a few releases ago for plugging optimisations into the pipeline, but the APIs required to write optimisations change a lot. They can't be C APIs, because they require inheriting from FunctionPass or similar (we could, perhaps, have a CFunctionPass class that had callbacks for the virtual functions, but it would be quite clunky). One of the goals of LLVM was that you'd be able to write optimisations that made use of the LLVM infrastructure but only made sense for a particular source language, or even set of idioms used with a particular library. I'd love to see, for example, Qt ship with a plugin that adds optimisations for their slots and signals mechanism. I wouldn't want this in the LLVM tree, because it's completely useless to anyone not using Qt, but currently the only way of guaranteeing that it will work one svn revision into the future is to put it in the LLVM tree. I currently have a GSoC student working on using LLVM for high-performance packet filtering. The front-end code could probably use the existing C APIs, but then there will be optimisations that are unlikely to make sense for any code that doesn't have this particular structure (e.g. prefetching the next packet based on knowledge of the structure of the network stack's ring buffers). Having an API that was at least useable for two releases for doing this, even if it spat out a lot of deprecated warnings in the second release, would be immensely helpful. David
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/llvmdevI'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