Hi,
I often use the gold plugin’s also-emit-llvm option to verify the final LLVM bitcode of a program. However, I realized that the gold plugin generates the bitcode file before running LTO optimizations, such that the changes performed by LTO are not reflected in the bitcode file.
What is the reason for this behavior?
Attached is a patch that would swap the order of the two actions, and cause the bitcode file to be emitted after link time optimization. What do people think about this?
Best,
Jonas
gold_emit_llvm_after_lto.patch (964 Bytes)
Hi Jonas,
Hi,
I often use the gold plugin's also-emit-llvm option to verify the final LLVM
bitcode of a program. However, I realized that the gold plugin generates the
bitcode file before running LTO optimizations, such that the changes performed
by LTO are not reflected in the bitcode file.
What is the reason for this behavior?
my guess: if the LTO optimizers crash, this is very helpful for debugging
because it gives you the input to the optimizers.
Ciao, Duncan.
The Apple ld (shipped with Xcode, open-source) saves the 3 files if -save-temps is applied:
- xxx.lto.bc : the merged bit-code before IPA
- xxx.lto.opt.bc: the optimized bit-code of the *.lto.bc
- xxx.lto.o : the object file of xxx.lto.bc
I think it is better way to go, often time we need IR both after and after the transformation.
Agreed. Jonas, would it work for you if the also-emit-llvm option did this?
Cheers,
Rafael
Certainly! I think this is an idea that would satisfy the needs of most
people.
The question remains how to name this option. If it is called
also-emit-llvm, I would expect to yield xxx.lto.opt.bc, i.e., the LLVM
corresponding to the regular linker output. If the option is called
-save-temps, it should give me all the intermediate files as explained by
Shuxin Yang.
I think a generic name like save-temps is probably best. With that in
we can add more intermediate files as needed and maybe even deprecate
also-emit-llvm.
Cheers,
Rafael