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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130604/a5217190/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: gold_emit_llvm_after_lto.patch Type: application/octet-stream Size: 964 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130604/a5217190/attachment.obj>
Hi Jonas, On 04/06/13 10:23, Jonas Wagner wrote:> 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.> > 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 > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
> > > I often use the gold plugin's also-emit-llvm option to verify the final > LLVMbitcode 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. >This is true. It also means that if the LTO optimizers don't crash, the bitcode is out of sync with the program. And not crashing is more common than crashing ;) The question is whether also-emit-llvm is an option intended for LTO debuggers or for LLVM end-users. I'd argue that it is very useful for end-users, and that LTO developers could get the bitcode through other means if they are researching a crash. At least from my personal point of view, I use also-emit-llvm frequently despite not working on LTO. How do other people use this? Best, Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130604/81409195/attachment.html>