llvm dev - Jun 2013 - [LLVMdev] Gold plugin: emit LLVM after LTO?

>
> > 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.
>
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>

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.

On 6/4/13 3:37 AM, Jonas Wagner wrote:
>
>     > 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.
>
>
> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130604/0c66f792/attachment.html>

On 4 June 2013 13:36, Shuxin Yang <shuxin.llvm at gmail.com>
wrote:
> 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