> Code is first and foremost for human consumption. The compiler's job is to worry about appeasing the machine.
Tangentially, it continues to frustrate me that C code organization directly impacts performance. Want to factorize that code? Pay the cost of a new stack frame and potentially non-local jump (bye, ICache!). Want it to not do that? Add more keywords ('inline') and hope the compiler applies them.
(I kind of understand the reason for this. Code Bloat is a thing, and if everything was inlined the resulting binary would be 100x bigger)
`inline` in C has very little to do with inlining these days. You most certainly don't need to actually use it to have functions in the same translation units inlined, and LTO will inline across units as well. The heuristics for either generally don't care if the function is marked as `inline` or not, only how complex it is. If you actually want to reliably control inlining, you use stuff like `__forceinline` or `[[gnu:always_inline]]`.
Regarding code size, it's not just that binary becomes larger, it's that overly aggressive inlining can actually have a detrimental effect on performance for a number of reasons.
Tangentially, it continues to frustrate me that C code organization directly impacts performance. Want to factorize that code? Pay the cost of a new stack frame and potentially non-local jump (bye, ICache!). Want it to not do that? Add more keywords ('inline') and hope the compiler applies them.
(I kind of understand the reason for this. Code Bloat is a thing, and if everything was inlined the resulting binary would be 100x bigger)