Subject: Re: LLVM 3.4 performance regressed?
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