Focusing on x86_64 (and linux), can you expand on what’s missing to reach ABI parity?

I haven't look much into it, but perhaps the sret fix mentioned above would fix some issues on x86-64. For the rest, this is mostly bug fixing (we probably don't handle the alignment everywhere) and fuzzing with ABI cafe.

And somewhat relatedly, are you leaning towards publishing an std component built with the backend or not?

I haven't thought much about this, but I guess an idea would be to ship a std for targets not supported by LLVM.

Would you expect the backend to be fully ready by the end of the year?

It depends what you mean by "fully ready", but this is unlikely. By "fully ready", do you mean feature-complete, without any known bugs, working on all GCC targets? Even with only x86-64, I don't expect to have all features: for instance, I don't plan on adding support for sanitizers/code coverage/PGO this year. And some stuff is outside my control: for instance, this Rust PR that will allow me to fix some ABI issues (unblocking, among other things, Aarch64) is waiting for review.

Or are there big/complicated blockers that remain, or LLVM-isms that make full or nearly full parity impossible?

Nothing complicated remains as far as I know. I don't think LLVM-isms is an issue anymore, so I would expect close to full parity to be possible (expect maybe supporting Thin LTO). The big remaining tasks are:

• Support for other architectures than x86-64 (and for SIMD on those targets)
• Debug info
• ABI parity

Relatedly, cranelift cg early struggles had to do, in part, with intrinsics support. I remember talk of somehow solving the problem systemically and not having to implement all of them in the backends directly? Where did things end up regarding that, and how does this backend deal with this problem?

There are Rust intrinsic fallbacks now, but I do not think all intrinsics have a fallback. And I'm not sure this applies to platform intrinsics.

And finally, using evcxr with :timing enabled, and switching between backends with :codegen_backend, I notice that gcc is the slowest when it comes to compile time. Is that because more IR is given to gcc to generate from, or is gcc/libgccjit itself slower now?

Compile times were never been a priority. At first, I thought libgccjit might be slower than GCC since it's not used much, but having used it for another project, it does not seem to be the case. My hunch is that since we need some hacks to convert from the lower-level IR MIR to the higher-level GCC IR, it's going to be hard to generate a very good IR in the end. So, we get a MIR that is not super optimized in terms of compile times and make it worse, so the impact on compile times probably lies there.

Well, LTO works in many cases, so it's not completely broken. I managed to do a refactoring in this PR, but I'm not entirely satisfied with the results yet (it prints stuff to stderr when LTO is not supported by the gcc installation). I have an idea to workaround this in order to land this PR which should help me continue fixing the issues we have with LTO.

LTO is very complex, though, so this is why it's taking time to move forward on this (same for unwinding support which also works in many cases, but not all).

Well, we can generate code for targets not supported by LLVM, but it is not trivial to setup (we hope to get rustup support in the coming months to make this easier) and most GCC targets won't pass as many tests as x86-64 with rustc_codegen_gcc. There's some info in the wiki about some targets that people tried.

It is an optional goal for the Google Summer of Code to bootstrap the rust compiler on other platforms, so we might be able to get a working rustc for new platforms by the end of the summer.

Oh, sorry for the confusion: this is about rustc_codegen_gcc which is a codegen plugin for rustc that uses libgccjit to generate the object files via GCC instead of LLVM, so it still requires rustc. There's another project that is a GCC frontend, called gccrs. Also, bootstrap is overloaded: in this case, a full bootstrap means that we can compile the Rust compiler with rustc_codegen_gcc, producing a stage-2 compiler, then recompile the Rust compiler with this stage-2 compiler to get a stage-3 compiler and those 2 compares as equal.

What do you think it means?