Richard,
But in the end, I haven't done the analysis which led to the decisions what to MAYBE_INLINE in CLN and what not. Bruno Haible did it back in the days of GCC 2.7, I guess. And I suppose that he did this as he usually does: by carefully reading the assembler output and basing these decisions on deeper insights than by looking at the sources.
The need to inline a function in some places and not in others came from three situations: 1) Some functions, like cl_SF_zerop or cl_FF_zerop, are just a single machine instruction when inlined, but I don't want to put the inline definition into the .h file because that would expose too many internals of the library in the .h file (leading to 1. violation of abstraction, 2. increased compilation times). Still I want to use the inline version of these functions in the library itself. 2) Some functions, like cl_{SF,FF,DF,LF}_idecode, are usually only invoked through a dispatcher cl_F_idecode that does nothing but dispatch the call to the right function. Here inlining is used, regardless of the size of the inlined functions, because it removes one function call from the chain of function calls. A compiler cannot know that this caller is the main caller for the 4 inlined functions. 3) Similarly, cl_I_from_NDS would be a bottleneck if not inlined: every creation of a new cl_I goes through this function. A compiler cannot know a priori the bottlenecks. In each case, I read the assembler output in order to verify that g++ had really inlined the functions as I wished. Bruno