@matthieum In reply to matthieum comments on Progress report on rustc_codegen_cranelift (Sep 2020)
First of all, thanks for your awesome work.
Thanks!
It may also open the door to further improvements -- I am curious as to the hints of in-place binary patching that Andrew Kelley dropped about his work on Zig, the idea being (apparently) to in-place substitute the new function code in the existing binary to completely skip linking again.
@lachlansneff pointed me to it by opening an issue. You may want to read my response there: In-place binary/jit updating · Issue #1087 · rust-lang/rustc_codegen_cranelift · GitHub
While there have been several PRs by other people like @osa1, @vi, @spastorino and @CohenArthur, I am the only person who has contributed more than a few changes to cg_clif.
Do you think it would be easier to draw contributors if your work was integrated in the rustc repository?
I have no idea.
Is there a clear view of when such integration would take place? #270 seems like a monster task on its own, but I don't see any mention of whether cg_clif is considered good enough already or if the compiler team would like to see some issues fixed first.
I already talked a bit about this in the git subtree section. To elaborate further: I already have a branch that makes it possible to build cg_clif as backend and even allows bootstrapping using cg_clif. It is a <1000 lines change. It doesn't extend the testing infrastructure as proposed yet though. The blocker for the past six months has been a bug in git subtree making it useless on the rust repo without using a patched git version.