Enable link time optimisation in builds about litex HOT 11 CLOSED

Having LTO on by default with a way to easily turn it off seems like a good plan. If LTO is off by default, it will just end up bit rotting until it no longer works.

from litex.

I have a WIP branch at https://github.com/mithro/litex/tree/enable-lto?files=1

from litex.

It is unclear why we have to link against libgcc when the symbols should be provided by libcompiler_rt. It seems to be because GCC is generating function calls itself (rather than being in the code) which cause lto to not understand that the symbols are used.

from litex.

This has been integrated with #401. For now it's enabled with for all processors except LM32. If this is causing issue with others configurations, we'll add a parameter be able to disable LTO when needed.

from litex.

LTO has been reverted in 979f98e since seems to cause subtle issues on some configurations. We'll have to test it more before enabling it.

from litex.

cc @mithro @mateusz-holenko.

from litex.

In case it helps, the link issue I had (in #417) with litex-buildenv was with the "stub firmware" in litex-buildenv, which uses the auto-generated litex compiler/linker/flags/etc, but has its own Makefile. So (copying from my comment on #417 (comment)), " updating the definition of $(LD) in common.mak instead of changing it locally in just the BIOS Makefile" might make these changes more robust (/consistent) for anything else that uses the litex generated compiler/linker/flags, etc. (It looks like that Makefile suffered from trying to use ld with flags intended for gcc, via $(CPUFLAGS), on lm32....)

Also (as I said in the same comment) maybe having a build time option to "force LTO off" would help anyone thinking their target is suffering from bad LTO handling.

In general I think it'd be a great idea to have LTO available as a build option, and probably even on by default.

Ewen

/cc @mithro @mateusz-holenko

from litex.

I'm also ok with that, we just need to work a bit more on it before integrating it.

from litex.

I just found this issue, should I close #682 which is a duplicate of this?

* [ ]  Have to link against libgcc

This is not necessary. It was required because libcompiler_rt was optimized out.

from litex.

should I close #682 which is a duplicate of this?

@DurandA It looks to me like #682 is much more active now. I'd probably lean towards closing this issue (which was already closed once, then reopened when the patch was reverted), with a comment like "LTO (re-)implementation work moved to #682"...

(Looks like @mithro or @enjoy-digital digital would have to be the ones to close this specific older issue.)

Ewen

from litex.

Let's keep #682 and close this one.

from litex.