Why a flag? In what case would you turn that analysis off separately from other optimizations?

Go is known by the speed of it's compiler, doing extra work during the compilation would slow it down. I would not mind either to have a "release" flag that would take minutes and produce a more optimized binary.

In a way, that's what the PGO mode of the compiler is

In theory that is what gccgo is for, in practice it is stuck in Go 1.18.

tinygo also tries really hard to produce an optimised binary, however it mostly optimises for size, not speed.

Yes this, I mainly use Go for it's simplicity and the speed of the compiler. What I don't want is Rust compile speeds.

As proven by D, OCaml, F#, Delphi, Ada, C++23 (with modules, VC++/clang 18), it is a matter of toolchain.

What we need is a Rust interpreter, or having something like Cranelift properly integrated, to only depend on LLVM when doing release builds on the CI/CD.

Having used Scala for some years with it's abysmal compile speed, I fear it has to do with complexity of the language and features, it was "implicit" in Scala, it might be the borrow checker in Rust (IANACG)

Note that I left out Scala, while I included other languages of similar complexity, exactly because improving compile times has never been a major focus in Scala land, versus features.

Example, development effort wasted on Scala 3 Python like syntax.

There are several performance reports that show that the major culprit is the pile of LLVM IR sent to the backend.

If you examine what takes time in the Rust compiler, the borrow checker is never a significant component.

The largest single bit tends to be codegen, which is why cargo check is so much faster than cargo build.

Ah!