RFC: Inlines, LTO and GCC

[Andrew MacLeod <amacleod at redhat dot com>]

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...

Andrew