Stream: t-compiler

Topic: State of inlining with ThinLTO

Tatsuyuki Ishi (Oct 02 2019 at 12:14, on Zulip):

I have been wondering recently if we could rely solely on ThinLTO for all inlining - that should work (from my understanding) with the exception of when dylibs are used (e.g. rustc).
So far I think all #[inline] imports are codegen-ed at downstream crates. Is my understanding correct and do you think the above idea is worth implementing?

mw (Oct 02 2019 at 12:18, on Zulip):

One way of experimenting with this without too much upfront implementation effort would be to modify the compiler to not duplicate inline functions across codegen units and then do performance tests with different numbers of codegen units.

mw (Oct 02 2019 at 12:20, on Zulip):

I suspect that ThinLTO can't quite reach the same runtime performance, but it might be worth a try.

mw (Oct 02 2019 at 12:21, on Zulip):

I could imagine -Copt-level=2 doing only ThinLTO while -Copt-level=3 would do the code duplication.

Tatsuyuki Ishi (Oct 02 2019 at 12:28, on Zulip):

I think that logic is implemented here but for non-optimized builds. Should I try having a build with this line changed?

Tatsuyuki Ishi (Oct 02 2019 at 13:22, on Zulip):

Actually there's a debugging opt so I can just do lolbench

Tatsuyuki Ishi (Oct 02 2019 at 23:39, on Zulip):

I'm abandoning lolbench since it keeps refusing to work, if anyone know a good alternative or whatever please let me know

Last update: May 27 2020 at 23:05UTC