[LLVMdev] Gold plugin: emit LLVM after LTO?

[Jonas Wagner]

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

[Duncan Sands]

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
> LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Jonas Wagner]

> 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

[Shuxin Yang]

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.

[Rafael Espíndola]

On 4 June 2013 13:36, Shuxin Yang <shuxi...@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

[Jonas Wagner]

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

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.

Cheers,

Jonas 

[Rafael Espíndola]

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