[CLN-list] Linking against cln fails when built with link-time-optimization

[Richard B. Kreckel]

Hi Bruno, Alexey,

On 27.09.20 00:09, Bruno Haible wrote:
>> The problem is *us* breaking the standard (ISO C++98) for performance reasons.
>> ...
>> To solve the problem properly we should either
>>
>> 1) Stop playing tricks and use the LTO. The bug report being discussed kind of proves that
>>      LTO actually works these days.
>> 2) Introduce `denominator_inline` and `denominator` and use the former in CLN itself
>>      (similarly to ce250e91fb8d16bc6b35be0add1896fc64f31ec1).
> 
> Thank you for this analysis; it's very clear. Yes, when possible, we want
> to avoid a function call for something that is just one or two instructions.
> 
> I vote for 2), using the technique that we already use for zerop_inline
> and minusp_inline.
> 
> Why? Because LTO is an undocumented implementation technique. 5 or 10 years
> from now, LTO may be out and JIT compilation may be the standard technique.(*)
> 
> CLN relied another undocumented implementation technique in the past: the
> per-file static constructor functions (for CL_REQUIRE, CL_PROVIDE). It was a
> big mistake and required major efforts to fix. (Thank you for these efforts!!)
> 
> Relying on LTO would likely bring similar problems a couple of years from now.
Okay, okay, we're all on the same page.

The case of numerator(cl_RA) and denominator(cl_RA) may not have been an 
ideal example: These functions aren't used at all internally. Instead, 
we always use the inline and private functions numerator(cl_RT) and 
denominator(cl_RT) because we handle the integer case first and do a 
DeclareType(cl_RT, x) then.

So, I'm now uploading a patch to remove the inline versions of these two 
functions.

But that's just the beginning.

   -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>