Deps: compiler_builtins

[ehuss]

This issue is for working through the implementation issues for compiling compiler_builtins.

The compiler_builtins crate provides various intrinsics needed by the compiler. This presents some portability and compile-time issues when building your own standard library.

There is the c feature of the crate that enables using a C compiler to build optimized versions of some intrinsics. This is the default for rustc.

There is the mem feature which demangles some memory functions, used in no-std builds of alloc. (rust-lang/rust#56825)

It wants a different codegen-units: https://github.com/rust-lang/rust/blob/1a1cc050d8efc906ede39f444936ade1fdc9c6cb/library/Cargo.toml#L14-L25

I'm not sure exactly how this will fit in the std-aware Cargo story.

[alexcrichton]

I believe that almost all intrinsics rustc uses have implementations in rust now at this point. It's largely a matter of time until they're as optimal as the C versions or more are translated. I think it's probably safe to conclude here that defaulting to rust implementations is the way to go and eventually supporting and opt-in C implementation is possible

[SimonSapin]

@alexcrichton Do you mean defaulting to rust implementations for all builds, including binaries shipped through rustup? If not, having a different default between those binaries and std built locally on demand by Cargo contradicts the goal that they should be as close to each other as possible, except for spending bandwidth v.s. CPU time.

I think this should be a goal, see the last part of my comment #5 (comment)

[alexcrichton]

Oh nah official rustup builds I think would still use C/assembly since the assembly versions are assumed to be faster and we haven't optimized the Rust ones. Additionally the not all C intrinsics have Rust versions yet, so there may be some esoteric things which haven't been ported which we need to fill out 100% of everything.

This may be a topic for a separate issue, but I would personally take it as a given that the official build of libstd and the cargo-built libstd would be different from the get-go. I think it'd be good to unify them in the long run but allowing for differences over time I think is what we'll need to tweak things in libstd as issues come up.

[Ericson2314]

This may be a topic for a separate issue, but I would personally take it as a given that the official build of libstd and the cargo-built libstd would be different from the get-go.

I'm sympathetic, but at the same time we dont want to expose "use the default binaries" in Cargo.toml, as it's sort of an ugly detail and hard to define what it really means if we change the way building and caching works.

Is it the case right now that std depends on compiler-builtins? compiler-builtins is one of those tricky cyclic dependencies we can't really properly express in Cargo.toml today. But as long as the implicit stdlib dependencies transitively include it we should be able to ignore that, treating the builtins like lang items.