Hacker News Reader

Comment by howenterprisey | Hacker News Reader

Does LLVM still take up much of the overall time spent by the Rust compiler? I was thinking of getting involved over there as the most effective way to make speed-ups happen.

View on HN

I remember reading that it does, but because the LLVM IR generated by rustc is verbose. If less IR was generated, LLVM would have less work to do.

I thought it was two factors (1) unoptimized IR and (2) large translation units (crate rather than file).

I think that's one of the eventual purposes of MIR (by both optimising Rust upstream from the LLVM IR generation and having a much simpler language to generate IR for), but I don't know if there's been work towards that yet.

> Does LLVM still take up much of the overall time spent by the Rust compiler?

The faster Rust gets the more overall time LLVM takes.

Would it be possible to write a rust compiler that skips llvm entirely?

Cranelift is being created as an alternative to LLVM, targeting a different set of requirements. Last I heard talk about Rust using it, the thought is that it would fit in well for fast debug builds but not be a good fit for optimized release builds.

See https://github.com/bjorn3/rustc_codegen_cranelift#not-yet-su... for progress

Probably yes, the LLVM linker is really slow

Really? I seem to recall lld being comparable to cp in speed, with the caveat that compacting debug strings can take a long time (if you enable that option).

Reference: https://fosdem.org/2019/schedule/event/llvm_lld/

Depends on the platform and the build type.

For example, on macOS in debug builds, the compiler and linker are reasonably fast, but then 2/3rds of the compilation time is spent in "dsymutil", presumably chewing through megabytes of the debug info.

Rust is only using LLD on ARM targets.

It's used on wasm as well.

Reply on news.ycombinator.com