dYou are talking incremental improvements. Radical is needed not just using cranelift for debug builds, but something like that for all builds. Current llvm model does not work well for delivering a fast compiler (opt and non-debug)
Re:Linux kernel in-tree Rust support
by steveklabnik on Saturday July 11, 2020 @11:15AM
(#23802756)
You can deliver radical improvements in an incremental fashion. The move towards a query-based architecture, and the rust-analyzer work, are both fundamental, radical improvements.
If anything, the cranelift stuff is less radical. Doesn't require any architecture changes, "only" involves implementing the backend API.
then there's also ongoing work in rustc_codegen_cranelift, which [as of 2 weeks ago] can now compile rustc:
https://github.com/bjorn3/rustc_codegen_cranelift/issues/743...
Re:Linux kernel in-tree Rust support
by steveklabnik on Saturday July 11, 2020 @11:55AM
(#23803085)
Yeah to be clear, I am very excited about cranelift too!
Sure, that's seriously cool but I don't see how it changes the material balance so to speak... If you still want llvm to codegen the same items, we don't have any radical departure at all, just a different way to do the same thing, when we are release-compiling any particular crate, from scratch.
Re:Linux kernel in-tree Rust support
by steveklabnik on Saturday July 11, 2020 @01:17PM
(#23803734)
Oh sure, if you're talking purely about a final release build, then yes. But most of the time, compiles are not final release build compiles. People don't generally complain about final release build times. They complain about the build time as they're developing.
Re:Linux kernel in-tree Rust support
by umanwizard on Sunday July 12, 2020 @09:14AM
(#23811080)
I regularly need to run release builds while developing. Not as commonly as I need to do a debug build or a cargo check, but still often enough that the slowness is annoying.
Re:Linux kernel in-tree Rust support
by vlovich123 on Saturday July 11, 2020 @01:41PM
(#23804027)
Final release build times are up there as build automation systems are often at capacity
Re:Linux kernel in-tree Rust support
by steveklabnik on Saturday July 11, 2020 @02:02PM
(#23804204)
For sure, and I don't mean to say that they don't matter. I have worked on codebases that only use release mode, for reasons, for example. I just hear less complaints about it, that's all I'm saying :)
Re:Linux kernel in-tree Rust support
by vlovich123 on Monday July 13, 2020 @01:10AM
(#23817374)
Usually I've observed release is used by automated systems and debug locally. If you're not managing the automation or working closely with those people, you're less likely to see those complaints but they definitely exist.
I'm referring to the rust-analyzer work, which is effectively an outside-in re-write of the compiler, if you squint at it right.
At the end of the day, rustc is a very large codebase, and has already undergone major architectural changes, and will be undergoing even more. It is not fast to steer a large ship in a new direction, but that is what is happening.
See https://pbs.twimg.com/media/ENC1ls6XYAEdKkv?format=jpg&name=... for a time I ran https://github.com/erikbern/git-of-theseus on the rustc codebase. Thank goodness Rust is such a good refactoring language.