CLN + GiNaC on MinGW

[Jonathan Brandmeyer]

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