[Tarantool-patches] [PATCH] cmake: add LTO support for building luajit

[Igor Munkin]

Olya,

Thanks for the changes!

On 17.04.20, Olga Arkhangelskaia wrote:
> Hi Igor!
> 
> It seems that I eventually had fixed white-space mess.

Yes, there are no tabs in the current patch! However there is a
misindent in the DARWIN-related part (see comments below).

> 
> While testing everything once again I came across reason why I separated 
> case with Darwin and
> 
> llvm-ar. Fixed and added a comment.
> 
> Diffs are below:
> 
> P.S.
> 
> Please, let me know whether new diff is better.

Sorry, but it's not. We can discuss it in tg to not spoil the ml.

<snipped>

Here is the update patch from the upstream:

================================================================================

From: Olga Arkhangelskaia <arkholga at tarantool.org>
Date: Tue, 3 Mar 2020 12:05:49 +0300
Subject: [PATCH] cmake: add LTO support for building luajit

Tarantool has LTO support, however while building luajit this opt. was
omitted. Patch adds necessary flag to turn it on.

Minimum compiler/linker versions: clang 3.4, gcc 5.0+, ld 2.27+ due
errors and slow work.

Closes #3743

Signed-off-by: Igor Munkin <imun at tarantool.org>
---
 cmake/luajit.cmake | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/cmake/luajit.cmake b/cmake/luajit.cmake
index 072db8269..d02c35432 100644
--- a/cmake/luajit.cmake
+++ b/cmake/luajit.cmake
@@ -225,6 +225,45 @@ macro(luajit_build)
         set(luajit_xcflags ${luajit_xcflags} -D${def})
     endforeach()
 
+    # Add LTO option to luajit
+    if (CMAKE_INTERPROCEDURAL_OPTIMIZATION)
+        message("Setting LTO flags for building luajit")
+        # Clang opt to support LTO
+        if (CMAKE_COMPILER_IS_CLANG)
+            if (${CMAKE_CXX_COMPILER_VERSION} VERSION_LESS 3.9)
+                set (luajit_cflags ${luajit_cflags} -flto=full)
+            else()
+                # ThinLTO that is both scalable and incremental
+                # due to parallel IPO, available since 3.9 and above.
+                # See http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html
+                set (luajit_cflags ${luajit_cflags} -flto=thin)
+            endif()
+                # Since Darwin uses DYLD_LIBRARY_PATH instead of llvm-ar
+                # ar should not be change.
+                # See http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160425/156799.html

I propose to mention the original patch[1] instead of the reply. By the
way, this fix differs from the one you mentioned: DYLD_LIBRARY_PATH is
set in the patch, but you just omit changing CMAKE_AR. Whether this fix
is related to our problem? Additionaly this if scope below is
misindented, please adjust it.

+                if (NOT TARGET_OS_DARWIN)
+                    # llvm-ar is just a wrapper over ar to pass --plugin= option,
+                    # so that ar can understand LTO objects.
+                    # See https://lists.llvm.org/pipermail/llvm-dev/2018-March/122018.html
+                    set (CMAKE_AR llvm-ar)
+                endif()
+        else()
+        # GNU opts to support lto
+            # Due to some problems (bugs, slow work, etc) we support LTO
+            # only for 5.0+. The same is for binutils prior to 2.27
+            # See comments in scripts/Makefile.lto in scope of
+            # the patch: https://patchwork.kernel.org/patch/10078207/
+            if (NOT ${CMAKE_CXX_COMPILER_VERSION} VERSION_LESS 5.0
+                AND NOT ${linker_version} VERSION_LESS 2.27)
+                set (luajit_cflags ${luajit_cflags} -flto -fuse-linker-plugin -fno-fat-lto-objects)
+             endif()
+            # gcc-ar is just a wrapper over ar to pass --plugin option
+            # so ar can understand LTO objects. For further info see
+            # -flto and -ffat-lto-objects options descriptions:
+            # https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
+            set (CMAKE_AR gcc-ar)
+        endif()
+    endif()
     # Pass the same toolchain that is used for building of
     # tarantool itself, because tools from different toolchains
     # can be incompatible. A compiler and a linker are already set
-- 
2.25.0

================================================================================

> 

[1]: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160425/156753.html

-- 
Best regards,
IM