Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Jonas Wagner <jonas.wagner <at> epfl.ch>
Subject: Re: LLVM 3.4 performance regressed?
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Wednesday 9th April 2014 08:42:10 UTC (over 3 years ago)
Hi,

> I wasn't aware of the gold linker plugin.


It doesn't seem to be that well known indeed... yet it's been the best way
to compile source to bitcode and bitcode to programs, in my experience.
Here are a few more hints (that may also be useful to others who stumble
upon this thread).

- To generate bitcode files from Clang, use -flto (or -emit-llvm)
- During linking, use -flto to accept bitcode files as input.
  Note that their extension matters (.bc gets compiled, LTO'd and linked,
.o gets just LTO'd and linked)
- You can obtain the merged bitcode file that corresponds to the final
executable as follows:
  - on Mac, pass -Wl,-save-temps to the compiler. This will give you both a
prog.lto.bc and a prog.lto.opt.bc file. One corresponds to the program
before link-time optimization passes were applied, the other after
link-time optimization.
  - on Linux, the corresponding command is -Wl,-plugin-opt=also-emit-llvm .
This only gives you the bitcode before link-time optimizations,
unfortunately. You can use the attached patch to make the behavior more
consistent between Linux and Mac.
- If your program creates libraries, you can make them contain LLVM bitcode
instead of regular object code.
  On Linux, this requires a few tweaks because nm, ar, ranlib etc. don't
know how to handle LLVM bitcode natively. Usually, passing the following to
the configure script helps:
  RANLIB="ar -s --plugin=/path/to/llvm/lib/LLVMgold.so"
  AR="ar -cru --plugin=/path/to/llvm/lib/LLVMgold.so"
  NM="nm --plugin=/path/to/llvm/lib/LLVMgold.so"

Let us know if this helps. Also, if anybody knows better workflows, I'd be
very interested.

Cheers,
Jonas
 
CD: 4ms