Please note: We are aware of an issue affecting replies on the Arm Community forums, which may not be loading as expected.

We apologize for any inconvenience and appreciate your patience while we investigate and work to resolve the issue.

Thank you for your understanding.

  • State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 21 subscribers
  • Views 12877 views
  • Users 0 members are here
Options
Related
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

mastupristi

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
  • 0 Arm Employee Badge in reply to mastupristi

    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
  • 0 Arm Employee Badge in reply to mastupristi

    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