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

[Alexey Sheplyakov]

Hi Bruno,

27.09.2020, 02:09, "Bruno Haible" <bruno at clisp.org>:

>>  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.(*)

I strongly disagree.

1. Cross-module/whole program analysis (which is a proper name for LTO) is a well
    established optimization method. And it's exactly the right way for the compiler
    to know that

    a)  cl_{SF,FF,DF,LF}_idecode are called mostly by cl_F_idecode (so it's a good
         idea to inline those 4 functions)
    b) every cl_I is created through cl_I_from_NDS (so it's a good idea to inline cl_I_from_NDS)

     etc.

2. Most (all?) major C++ compilers (GCC, clang, msvc) provide cross-module/whole program
    analysis. In fact it has been available for (almost) two decades. LTO branch has been
    merged into GCC trunk back in 2009. Link time code generation (which is msvc name
    for cross-module analysis) has been available since visual studio 7.0 (released in 2002).

Therefore I prefer the "Stop playing tricks and use the LTO" solution.
 
> 5 or 10 years from now, LTO may be out and JIT compilation may be the standard technique.
> Relying on LTO would likely bring similar problems a couple of years from now.

Firstly any reasonably efficient piece of the software should be adapted for the new
hardware and compilers. As long as the software is useful there will be someone to
update/fix it (cf. CL_REQUIRE/CL_PROVIDE story).

Secondly I don't think cross-module analysis is going to disappear. These days there are
quite a number of large (C++) codebases (think of Chrome, clang, etc), and without
the cross-module analysis such a code quickly gets either too messy or too slow.
I think it's more likely for C++ itself to disappear in 10..20 years.


Best regards,
      Alexey