Note that it is up to the compiler frontend to choose which LLVM optimization passes to call, in which order and how often. But neither clang[0] nor rustc[1] d

Note that it is up to the compiler frontend to choose which LLVM optimization passes to call, in which order and how often. But neither clang[0] nor rustc[1] do something that resembles hotspot C2's incremental inlining[2]. It is fairly expensive, so hotspot's benefit here is that it only has to spend the optimization cycles on the hottest code. > It's one of the major reasons benchmarking C/C++ code is so damn hard, the optimizer tends to eliminate the entire thing. This is totally a thing in java too. That's why the java microbenchmark harness (JMH) provides helpers that can inhibit DCE, constant propagation and inlining [0] https://www.youtube.com/watch?v=s4wnuiCwTGU https://www.youtube.com/watch?v=s4wnuiCwTGU [1] https://github.com/rust-lang/rust/issues/44041 https://github.com/rust-lang/rust/issues/44041 [2] https://bugs.openjdk.java.net/browse/JDK-8005071 https://bugs.openjdk.java.net/browse/JDK-8005071