llvm dev - Oct 2008 - [LLVMdev] why doesn't LLVM link its dependencies dynamically?

Hi everyone. I'm mainly build the debug versions of lli and opt which are
huge and take up to 10 seconds to build. It seems there is no option in
configure to allow dynamic linking. Before I try to add it myself, is there
a reason why it's not done?

On Fri, Oct 3, 2008 at 6:14 PM, Yale Zhang <yzhang1985 at gmail.com>
wrote:
> Does anyone know if LLVM will soon have a dynamic optimization
> infrastructure, namely support to generate trampolines back to the
> JIT/execution manager that get run when a piece of code's frequency
exceeds
> a threshold? I see that there already is a relinkAndRecompileFunction in
the
> JIT, which will be useful. Rather than roll my own mechanisms and have to
> worry about jumping back to code that gets replaced, are there already
works
> in progress?
>
> Also, is there a way to generate platform independent trampolines (e.g.
> generate IR that calls a function pointer to the execution engine I want to
> go to). LLVM seems to be pretty strict about type casts, so I was afraid I
> wouldn't be able to generate a function pointer initialized to
arbitrary
> data.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20081006/c260ca52/attachment.html>

On Oct 6, 2008, at 15:52, Yale Zhang wrote:
> Hi everyone. I'm mainly build the debug versions of lli and opt  
> which are huge and take up to 10 seconds to build. It seems there is  
> no option in configure to allow dynamic linking. Before I try to add  
> it myself, is there a reason why it's not done?
In addition to the APIs being insufficiently stable for shared  
libraries to be of much use per se, it invoked pathologically bad  
performance in some dynamic link editors--startup times greatly  
exceeding your link times.

— Gordon

OK. I've tried using shared libraries for everything except LLVMX86.o, and
the build time improvement isn't as good as I hoped for. On a Dell Precision
390 workstation, the time to rebuild after a one line change in a library is
10 s for static linking and 7.3 s for dynamic linking (building in Eclipse
is slower).

One advantage of static linking I haven't thought about is that only the
needed functions need to be loaded, unlike everything for dynamic libraries.
The space saving is huge though: 1350MiB vs 723MiB and the IO load is
probably greatly reduced.

I've added a hackish script that patches LLVM 2.3 to use dynamic libraries
if anyone wants it. Just run it after configuring.

On Tue, Oct 7, 2008 at 10:50 AM, Gordon Henriksen <gordonhenriksen at
me.com>wrote:
> On Oct 6, 2008, at 15:52, Yale Zhang wrote:
>
> > Hi everyone. I'm mainly build the debug versions of lli and opt
> > which are huge and take up to 10 seconds to build. It seems there is
> > no option in configure to allow dynamic linking. Before I try to add
> > it myself, is there a reason why it's not done?
>
> In addition to the APIs being insufficiently stable for shared
> libraries to be of much use per se, it invoked pathologically bad
> performance in some dynamic link editors--startup times greatly
> exceeding your link times.
>
> — Gordon
>
>
> _______________________________________________
> 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/20081007/6dfe4b6d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make_llvm_use_shared_libs
Type: application/octet-stream
Size: 1075 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20081007/6dfe4b6d/attachment.obj>