CLN + GiNaC on MinGW

[Bruno Haible]

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