How standard libraries compiled for distribution?

I recently made a change in STD and noticed that functions I added not inlined (e.g. <&[u8]>::spec_new_impl not inlined into <&str>::spec_new_impl) as I expected.

Also, CString::from_vec_unchecked not inlined into <&[u8]>::spec_new_impl.

However, those inlining happens when I enable fat LTO so I think they would be inlined if std would be built with -Ccodegen-units=1.

Are distribution builds of libraries (e.g. stable releases and nightlies) built with codegen-units=1 or not?

The standard library is built with codegen-units=1. In this case however what matters is if the user crate is compiled with codegen-units=1 (or LTO) as CString::new is codegened in the user crate due to being generic.

4 Likes

Thank you for your response. Is local builds (which I do with pypy3 x.py build library/std --stage 1) built different than distribution?

I actually told about SpecNewImpl::spec_new_impl which used to specialize. While CString::new is inlined as generic, specialization trait specializations isn't (which is fine).

But I don't like how CString::new_unchecked wasn't inlined into SpecNewImpl::spec_new_impl specializations and <&[u8] as SpecNewImpl>::spec_new_impl wasn't inlined into &str and &mut [u8] implementations. I even tried to move implementation to separate function marked as #[inline] but this didn't help.

Not by default. codegen-units and codegen-units-std both default to 1.

Do they? I'm pretty sure both default to 16 (and probably 256 with incremental), same as for all release profile builds per the Cargo docs.

This seems to match the comments in config.toml.example as well, and at a cursory look the code.

They default to 1 for the standard library build.

Can you point me at why you think so? We should update the documentation in config.toml.example at minimum -- it currently does not indicate a default of 1 by my reading.

We do set it to 1 in CI though.

1 Like

Looked at an config.toml based on an old config.toml.example it seems. My bad.