I suppose that that metric will be different between compilers (msvc vs gcc vs clang (which we don't officially build with, but I bet is the easiest to get the info out of)), and possibly between platforms, versions, etc. I wouldn't be surprised if the context in which the header is included makes a difference too (by influencing the size vs speed optimisation tradeoff). Even if the compiler doesn't inline a function, it could still be inlined by LTO/PGO and that is practically non-deterministic. So, getting a list of 'methods which are actually inlined' is probably not possible in any meaningful way.
We could probably do a better job of deciding when methods are put in the header and when they are put in cpp files though. The current metric is undefined and vague at best. Also, how much we put in the header vs the cpp varies a lot by module. Cheers, Nick On Friday, September 13, 2013 9:59:30 AM UTC+12, Julian Seward wrote: > On 09/12/2013 11:08 PM, Chris Peterson wrote: > > > On 9/12/13 6:35 AM, Mike Hommey wrote: > > >> Note we have *many* inline functions that the compiler decide to never > > >> inline. We should maybe try to detect those on all platforms and move > > >> those functions out of headers. > > > > > > gcc -Winline will report uninlined "inline" functions, but the warnings are > > > VERY noisy and sensitive to compilation flags. Still, periodic -Winline > > > "spot checks" might be useful to identify the most frequently uninlined > > > functions. > > > > Presumably gcc must compute some "desirability of inlining" metric for each > > function, and use that to make a yes/no decision. Is there a way to get it > > to show such information, so we can at work through the > > erroneously-in-header-file functions in least-contentions-first ordering? > > > > J _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
