> I think there's a deeper problem in that the program can't easily tell the compiler what to do Yes. We have divisions - application, language library, langua

> I think there's a deeper problem in that the program can't easily tell the compiler what to do Yes. We have divisions - application, language library, language implementation - which are broadly convenient but drop information on the boundaries. The implementation probably pattern matches on the library and the library will probably depends on quirks of the implementation (e.g. compiler intrinsics written for it), but the application is unlikely to be be able to extend the implementation. In cases where it can, there's a tendency to call it monkey patching and disapprove. > people mistake inlining to be solely about call-overhead and not specialization Yeah, that sounds like me. Inlining is an approximation to per-callsite specialisation which is easier to implement, where you pay for ease of compiler development with (machine) code duplication. attributes noinline and alwaysinline are relatively likely to exist, but specialise with respect to the third parameter is still on a wishlist. This is in the ballpark of compilers could be better, and should be better, than the current state of the art.