jahboater wrote:The "always inline" bit forces the compiler to actually inline things, nice and simple.
The keyword seems to be ignored in about 3/4 of cases!
I think I should understand exactly why that is ...
I would much rather use the keyword.
Well it is allowed to ignore the inline hint.
Possibly the compiler decided that inlining the code wasn't worth it most of the time. Usually the compiler is in a good place to see the costs. Unfortunately -fopt-info-optimized
doesn't seem to give any output but you can get early inlining information by requesting internal dumps. -fdump-tree-einline
has lots of data (including the internal representation of the code). At the start of each function it tells you which functions were considered for inlining and whether they were or not (you can get more info with -fdump-tree-einline-details
Then again, there's more data in -fdump-ipa-inline-details
, that gives you information like (although it produces even bigger files, lots of data) :-
Code: Select all
not inlinable: rshapes/51 -> rseed/50, function not declared inline and code size would grow
not inlinable: main/56 -> sunearth/52, call is unlikely and code size would grow
I didn't define rseed inline, the optimiser thought about it and decided it wasn't worth it. I did ask it to inline sunearth, the optimiser decided again it wasn't worth it even though I asked for it.
These options aren't really meant for regular users of gcc, more for developers of gcc to see what's going on, and it's been quite a few years since I really looked into it's inner workings.