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

Reply via email to