On Mon, 2003-11-03 at 15:10, Bruno Haible wrote:
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
Thanks for the analysis. It turns out that not all of these functions are being inlined now, although I trust you when you say that they were in the past. Instead, several cases are being emitted as weak symbols out-of-line and then being linked against the global copy. Since weak symbols are not supported on MinGW (probably a PE/COFF limitation), they are instead causing multiple definition errors. There is a way to prevent this from happening. If the functions in question are defined like this: // Declaration qualifiers ret-type foo( args) FORCE_INLINE; MAYBE_INLINE ret-type foo( args) { ... } The calling functions can #define FORCE_INLINE to be __attribute__((always_inline)) to force inlining. This define must be provided before #including the header for the function being inlined. I cannot read assembly code. However, I have used the output from nm to verify the behavior I have described. Would you accept a patch that implemented this change? Thanks, Jonathan Brandmeyer