[PATCH] New tool libLLVM.dylib for clients who want to dynamically link all of LLVM

[Sean Silva]

On Tue, Aug 19, 2014 at 11:47 AM, Chris Bieneman <cbieneman at apple.com>
wrote:

>
> On Aug 19, 2014, at 11:03 AM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
>
>
> On Tue, Aug 19, 2014 at 10:13 AM, Chris Bieneman <cbieneman at apple.com>
> wrote:
>
>> Initially the biggest difference is the exported API, what parts of LLVM
>> are linked into it, and the file size. The patch I’m proposing exports the
>> full C API, pulls in a few parts of LLVM that aren’t in libLTO (like the
>> JIT), and results in a dylib a little less than 10% bigger.
>>
>
> Keep in mind though that due to virtual memory, it may be worthwhile to
> have everyone load a 10% bigger dylib (and have the kernel just not page in
> the unused parts) vs. having two separate dylibs that might have
> overlapping functionality resident.
>
>
> Agreed with the caveat that you don’t want to include content that isn’t
> used by any clients. This is actually the motivation for why I want to
> support using the command line to specify which LLVM libraries to include
> in the library and dynamically generating the export list.
>
>
That's the opposite of what I was saying, which was that the kernel will
only page in stuff that is used, so just doing this to reduce file size or
memory footprint might not be worth it (and might actually be detrimental
if there are multiple simultaneous LLVM users on the system).

-- Sean Silva


> -Chris
>
>
> Having a single dylib might also net you some cache advantage since the
> last-level caches typically use real addresses, and so can be shared among
> processes across a context switch.
>
> -- Sean Silva
>
>
>>
>> I’m also hoping to do some more work in the build configs to support
>> users dynamically specifying which components to include in libLLVM, and
>> having the build process automatically generate the export list.
>>
>> -Chris
>>
>> > On Aug 19, 2014, at 9:54 AM, Bob Wilson <bob.wilson at apple.com> wrote:
>> >
>> >
>> >> On Aug 18, 2014, at 3:51 PM, Chris Bieneman <cbieneman at apple.com>
>> wrote:
>> >>
>> >> This patch adds a new tool libLLVM.dylib which exports the full C API,
>> and can be optionally built for clients who want to link LLVM dynamically.
>> >>
>> >> I will be working on some more build system extensions to allow users
>> to better fine-tune the dylib to their uses.
>> >
>> > Chris, I haven’t yet looked at this is detail, but I’m wondering how it
>> relates to libLTO.dylib. At least on Darwin, we have gradually been
>> expanding the use of libLTO.dylib for things besides LTO, adding various
>> other functions from the C API, with the intention that it would eventually
>> become an alias for libLLVM.dylib. Would this be a good time to make that
>> transition?
>> > _______________________________________________
>> > llvm-commits mailing list
>> > llvm-commits at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140819/510076fb/attachment.html>