Optimizing for size usually reduces the dial on inlining heuristics, yes, but some "inlining" is mandatory due to the language's treatment of polymorphism, every monomorphized instance is essentially an "inlined copy" of the code. I'm not sure what the cause of the code blow-up was in the case you're describing, 10x size seems a bit much toggling between Os and O2 -- I just did a size test on one of my crates and it varied between 4.18mb at O2 and 4.15mb at Os -- but maybe there's a specific punitive inlined or devirtualized abundant leaf function in there somewhere (or maybe it did really aggressive unrolling to try to vectorize, or .. who knows, there are a lot of passes!)

(silly question: are you sure you're not accidentally toggling debuginfo, panic strategies, etc. that happens all the time with cargo profiles..)

@graydon @barrelshifter And of course reducing the dial on inlining heuristics may be bad for code size. The obvious first order effect is that more inlining increases code size. But if you do enough inlining you often allow some intraprocedural optimization to dramatically reduce or eliminate some code. That code may be smaller than the completely un-inlined version.

One example, and a bee in my personal bonnet, is Rust's Vec resize. resize is large and has many call sites, but is relatively cold at runtime compared to the other code near those call sites. (Lots of Vec stores; most store operations won't perform a resize.) resize is thus a poor candidate for inlining: that would add lots of code size for little if any speed improvement.

So you don't inline it. But what if this code turns out to be unused? The compiler might be able to optimize away a Vec store or even an entire Vec, but if resize is out-of-line then the optimizer likely won't be smart enough to recognize it. Failing that optimization is bad for both speed and code size.

So you have to inline it to enable those optimizations. But now every Vec store that doesn't get optimized away has inlined a giant blob of cold code.

Thus the trap: deep inlining is very bad for code size, but lack of inlining is also very bad for code size. Too many compiler optimizations require inlining to succeed. That inlining is expensive. Cleverer ideas are needed.

Going back to Matt's original question: -Os can be powerful, but it works best for "simple" code. The more abstractions you write, expecting the compiler to optimize them away, the more likely -Os will miss some important optimization opportunity and tank your performance.

@graydon @barrelshifter The big problem is that Vec resize often really is called, but it's not a hot path so you'd prefer it be out-of-line for code size. One out-of-line copy of Vec resize (or more usually one copy per Vec type, from monomophization) is not so bad for code size. The outcome to avoid is inlining another copy of resize at each of many many Vec stores.

A lesser problem is that the compiler probably needs to inline lots of other things before it can see that a particular resize is never called, and -Os is less likely to reach that inlining depth.

The really valuable optimization here for both speed and size tends to be eliminating entire Vecs, or reducing them to fixed-size stack storage instead of heap allocations. An out-of-line resize is often enough to defeat these optimizations. If the compiler could see all loads and stores from a Vec's backing storage then its optimizations could start chipping away at it, but intraprocedural analysis can't see into a live out-of-line resize.

You need an LLVM special-case analysis or higher-level IR that knows what Vec resize does (an IR called SIL is how Swift optimizes its arrays), or an LLVM general-purpose interprocedural analysis that can communicate enough information about resize's contents to enable these optimizations at out-of-line call sites.