I’m happy that unwinding is finally fixed: that was the biggest unknown for me. I’m also happy that we have very few UI tests from the Rust test suite that fail now: there are still some other test suites to run, but having only 21 failures among the UI tests is a big achievement.
I’ve been watching the number of failing UI tests shrinking fast with excitement.
Would you expect the backend to be fully ready by the end of the year? Or are there big/complicated blockers that remain, or LLVM-isms that make full or nearly full parity impossible?
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?
And finally, using
evcxrwith:timingenabled, 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?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.
Thank you for your detailed reply.
Focusing on x86_64 (and linux), can you expand on what’s missing to reach ABI parity?
And somewhat relatedly, are you leaning towards publishing an std component built with the backend or not?