[howenterprisey]

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.

[nindalf]

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.

[masklinn]

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.

[epage]

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

[fluffything]

> 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.

[empath75]

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

[epage]

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

[rehemiau]

Probably yes, the LLVM linker is really slow

[mtzet]

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/

[pornel]

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.

[GrayShade]

Rust is only using LLD on ARM targets.

[est31]

It's used on wasm as well.