@if lto: clang.options.linker = "-flto -B /home/stefan/ldgolddir -ldl" clang.options.speed = "-O4 -flto -B /home/stefan/ldgolddir" gcc.options.linker = "-flto -B /home/stefan/ldgolddir -ldl" gcc.options.speed = "-O4 -flto -B /home/stefan/ldgolddir" @end
So I can compile for lto with
nim c -d:lto -d:release myprog.nim
Works fine. (For that example I use O4, which is identical with O3 for gcc, and which enables LTO for clang -- without O4 flto is needed.)The only difficulty was, that clang need the gold linker for LTO -- for my Gentoo box that is now the default, but it may be not the default for everyone. The trick to make it work is creating a soft link to the gold linker binary, for me that is ld -> /usr/bin/ld.gold in ~/ldgolddir/ . The -B option is needed to use this linker. (Making gold linker the default may be a bit dangerous, for example in the past it gave unusable binary for grub, which makes the box unbootable, That may be fixed now.) gcc LTO can be used without gold linker. This is for Linux of course.
Jehan seems to be not a big fan of LTO: http://forum.nim-lang.org/t/607#3306
Jehan seems to be not a big fan of LTO
To clarify: There's a trade-off here in that LTO can significantly add to link time (especially for large programs), without increasing the execution speed of the program by all that much (though that depends on a number of factors). I wouldn't want it to be the default, but then I also rarely need full -d:release speedup and often combine it with at least basic memory safety options, so I have a natural bias.
and a small test executable echo "Hello world went from 61 KB to 35
That is true, but not really new information. We discussed that a few times in this forum already, I think I mentioned it one year ago for the first time. For example the toy chess is 125k with gcc O3, about 95k with gcc O3 LTO, and only 70k with clang O4 LTO. 60k stripped.
But I think LTO will not really increase performance, which may be more important for most people.
I asked myself a long time why LTO has such a big effect for size of Nim executables, and not for most ordinary C software. Recently someone reported that Nim procs do not get static keyword in C code, so C compiler can not remove unused functions without LTO. That may be one reason.