codegen-units + ThinLTO is not as good as codegen-units = 1

[nagisa]

We recently had a fair amount of reports about code generation quality drop. One of the recent causes for the quality drop is the enablement of codegen-units and ThinLTO.

It seems that ThinLTO is not capable of producing results matching those obtained by compiling without codegen-units in the first place.

The list of known reports follows:

• 2x benchmark loss in rayon-hash from multiple codegen-units #47665
• Performance regressions of compiled code over the last year #47561
• Performance regression on pest in newest nightly #47356
• Performance regression with nightly benchmarks. #47062 (specifically this comment)
• Performance regression on nightly (when using Cursor::read_exact and Byteorder) #47321
• ThinLTO bloats size of bare metal programs by up to 1200% #47770
• 35% performance regression in generated code since 1.24 #53833

Improvements to ThinLTO quality are inbound with the soon-to-happen LLVM upgrade(s), however those do not help sufficiently, it would be nice to figure out why ThinLTO is not doing good enough job.

cc @alexcrichton @nikomatsakis

[nikomatsakis]

Thanks for filing this @nagisa =)

[alexcrichton]

Indeed thanks! I'll try to take a closer look at this when we've upgraded LLVM

[matthiaskrgr]

By the way there is a great talk about how thinlto is designed here: https://www.youtube.com/watch?v=p9nH2vZ2mNo in case people are curious. :)

[robsmith11]

Matrix multiplication is slower with thinlto + multiple codege-units using https://github.com/bluss/matrixmultiply .

I can create a minimal example if needed.