On 10/09/13 04:44, Jeff Law wrote: > On 09/09/2013 02:45 PM, Andrew MacLeod wrote: >> A number of header files have inline functions declared in them. Some of >> these functions are actually quite large, and I doubt that inlining them >> is the right thing. For instance, tree-flow-inline.h has some quite >> large functions. Many of the op_iter* functions are 30-40 lines long, >> and get_addr_base_and_unit_offset_1() is 130 lines. Doesn't seem like >> it should be static inline! :-P >> >> During the process of re-factoring header files, it could be worthwhile >> to also move functions like this to a .c file... >> >> I know a lot of work has going in to the inliner and LTO, and I was >> wondering what its state was with regards to the current gcc source base. >> >> My questions are: >> >> 1) is everyone in favour of moving these largish inlines out of header >> files and making them not inline, >> 2) what size of function is rationale for inlining. Small one obviously, >> but where does the line start to get vague, and what would be a good >> rationale litmus test for an inline? Functions which "do a lot" and >> look like they would use a number of registers seem like candidates to >> move.. I think we have a lot of functions that end up being compiled >> quite large because they inline functions which inline functions which >> inline functions.... >> 3) The significance of moving these out would be greatly reduced if GCC >> were produced with LTO.. have we tried or considered doing this and >> possibly releasing gcc compiled this way? It seems to me we could have >> significantly less stuff in header files tagged as inline, but still >> see the benefit in our final product... maybe all we'd need is the >> teeny tiny ones... and let the machinery figure it all out. Now that >> would be sweet... > Unless we have evidence to show inlining a nontrivial function is a > performance win, my inclination is to not have them in .h files and > decorate them with inline directives. Instead put them back in a .c > file where they belong and let LTO do its thing. > > I haven't done any research, but I suspect once you go beyond the > trivial functions size is no longer a good indicator of whether or not > something should be inlined. Instead I suspect the question should be, > if I inline this nontrivial code, how much code either in the caller or > the inlined callee gets simplified away. Of course, that's not always > an easy question to answer :-) > > Jeff >
This last point is crucial. I haven't looked at the code in question, but one point to check is how the functions are called. If they are often called with constant values, then they may be very much simplified due to constant propagation. Secondly, if a function is inlined, the compiler has full knowledge of the effects of the function "call" and can thus optimise better (keeping data in registers over the "call", shuffling around loads and stores, etc.). Finally, if the functions are called in loops or other time-critical code, it can be worth spending more code section space for a faster result (but sometimes smaller code is faster due to caches, branch prediction buffers, etc.). The ideal situation is that LTO figures this out for you, and the code can go as normal non-inline functions in a C file. But if you are not compiling with LTO (or not yet, anyway), then check the usage of the functions before moving them. David
