Hello,
I have observed that the LLVM build takes pretty long time
to link executables (i.e. tools). Is that a normal behavior?
Thanks,
Rahul
Rahul Joshi wrote:
Hello,
I have observed that the LLVM build takes pretty long time
to link executables (i.e. tools). Is that a normal behavior?
It depends on what hardware you are running, but yes, I would say that the link time for the LLVM tools is on the longer side.
You could try to trim it down by building non-debug executables or by manually adding linker options to strip unnecessary symbols (if using GNU ld). If these things speed it up, please let us know.
Just out of curiousity, what sort of hardware are you using?
Thanks,
Rahul
_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-- John T.
Yes, we've noticed that too, on our (slower) Sparc machines.
Works much nicer on our shiny faster X86 machines though. 
Please note that you do not need to relink *all* the tools unless you
really are using *ALL* of them. Different tools use different subsets of
libraries, and if you are linking ALL the tools, that's a lot of linking
of similar sets of libraries, over and over (and they can get big). For
example, many tools use the VMCore and bytecode reader/writer.
So just edit llvm/tools/Makefile and exclude the tools you do not use,
your builds will be much faster.
You can thank the binutils people for this. From what I've heard, they've
been doing some work to improve link times with "optimizations" like not
using a fixed number of buckets in critical hash tables.
In terms of practical suggestions, here's some ideas:
1. Try getting a newer binutils (ie, ld) than you already have. It may be
improved.
2. If you can, build stuff into shared objects and load it with -load.
This is only really feasible if you're working on llvm-to-llvm passes.
3. Debugging information is what really slows stuff down. If it is
useful, compile with ENABLE_OPTIMIZED on. Without debug information,
link times are _very_ short.
4. Like Misha said, you can get away with not rebuilding some of the tools
if you're not using them. Be careful though, because you don't want to
accidentally get out of date and not know it. The makefiles already
only rebuild the correct set of tools based on which libraries get
modified.
Hopefully this will help, if not, the binutils sources are available.
-Chris
Rahul,
More than anything else, make sure that you are writing into a local
filesystem and not an NFS one. That can reduce link times by an order of
magnitude -- writing over NFS is painfully slow. That's why we put our
obj tree in /localhome on our machines.
--Vikram
http://www.cs.uiuc.edu/~vadve