This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

GNU Arm Embedded ld with LTO support

The current version 7-2018-q2-update of GNU Arm Embedded Toolchain contains arm-none-eabi-ld.bfd, so it does not support Link Time Optimization (LTO).
Is there a problem if I try to compile the LTO version? Is the new linker lto hoping to work? Why wasn't it done? Both versions could be distributed, bfd and lto.

best regards

Max

Parents
  • flto has no effect on ld. It is a gcc option. If you print out the -v when you do

    $ ./arm-none-eabi-gcc -O2 -flto  -specs=rdimon.specs foo.c -v --save-temps

    You will see that the collect2 wrapper invokes the liblto_plugin.so  which then reads all the GIMPLE bytecode, invokes lto1 which then subsequently calls the compiler-proper(via the driver) for all the gimple optimization and eventually you have the binary output.

    I would encourage you to have a look at the -v output if you want to go deeper into how the lto call sequence works. --save-temps will give you all the intermediate files generated.

Reply
  • flto has no effect on ld. It is a gcc option. If you print out the -v when you do

    $ ./arm-none-eabi-gcc -O2 -flto  -specs=rdimon.specs foo.c -v --save-temps

    You will see that the collect2 wrapper invokes the liblto_plugin.so  which then reads all the GIMPLE bytecode, invokes lto1 which then subsequently calls the compiler-proper(via the driver) for all the gimple optimization and eventually you have the binary output.

    I would encourage you to have a look at the -v output if you want to go deeper into how the lto call sequence works. --save-temps will give you all the intermediate files generated.

Children
No data