Ok, I couldn't get -flto to work when building the compiler (cf. prev.
mails in this thread), but I did some time-consuming tests and came
so far to this (personal) conclusion:
The following vars (as params to configure) can be set with own
(optimization) options (except of course -flto for the first two).
For example "-Ofast -DCLS=$(getconf LEVEL1_DCACHE_LINESIZE) -fPIC
-fprefetch-loop-arrays -mrecip=all -funroll-loops", and some more.
(Here some options indeed can be redundant with the used -Ofast option).
Btw, I chose them b/c fpmath accuracy is not that important for my current
project).
...
CXXFLAGS_FOR_BUILD="$my_CXXFLAGS_FOR_BUILD" \
CXXFLAGS_FOR_TARGET="$my_CXXFLAGS_FOR_TARGET" \
LDFLAGS="$my_LDFLAGS" \
...
(Interestingly, LDFLAGS can have also -flto)
In my case all 3 have the same value, except LDFLAGS having additionally also
-flto.
The resulting compiler reduced the build time of the compiler itself
(languages=c,c++)
from previously ~ 15 minutes down to ~ 12 minutes (quadcore x86_64 @3.9 GHz
w/SSD, Linux),
ie. a performance gain of ~ 20%.
Xi Ruoyao wrote on 06/15/2018 03:35 PM:
On 2018-06-15 15:16 +0200, U.Mutlu wrote:
Xi Ruoyao wrote on 06/15/2018 11:57 AM:
On 2018-06-15 11:31 +0200, U.Mutlu wrote:
I tried to use -flto in CXXFLAGS_FOR_TARGET. It successfully built the compilers,
but later when trying to use the compilers, the linker reported an error about
something missing and aborted the linking.
PR 48200 renders shared libraries with versioned symbols (".symver") unusable if it
was built with -flto. libstdc++ is affected.
Of course the rationale was to optimize the compiler itself.
So, the question is: does it not make any sense to use -flto for the build itself?
(Or should one specify -flto in some of the other config variables like
CXXFLAGS_FOR_BUILD and/or the ...FLAGS vars maybe?)
Use --with-build-config=bootstrap-lto.
"C(XX)FLAGS_FOR_BUILD=-flto" also makes sense (see PR 59893). But you should use
--disable-shared and build the shared libraries w/o LTO, at least for now to
workaround PR 48200. And you should use patch to workaround PR 60160.
Thanks, also for the useful references.
The patch is somewhat old (from 2014), and applies only partially
to the latest repo revision (I have to analyse it further yet).
The build finishes, but gives such warnings:
BFD: tsan_clock.o: plugin needed to handle lto object
...
BFD:
.libs/libtsan.lax/libsanitizer_common.a/sanitizer_symbolizer_libbacktrace.o:
plugin needed to handle lto object
...
And compiling a C++ program with this newly generated compiler
gives the said libstdc++ link errors:
/usr/local/gcc-latest/lib/gcc/x86_64-linux-gnu/9.0.0/../../../../lib64/libstdc++.so:
undefined reference to `std::istream::ignore(long)'
/usr/local/gcc-latest/lib/gcc/x86_64-linux-gnu/9.0.0/../../../../lib64/libstdc++.so:
undefined reference to `std::basic_istream<wchar_t, std::char_traits<wchar_t>
>::ignore(long)'
collect2: error: ld returned 1 exit status
But, I'd skipped the bootstrap process (via --disable-bootstrap).
Is it necessary for this to work?
Seems I was wrong about --disable-shared. It could not suppress libstdc++.so
but suppressed the LTO plugin.
Do not use --disable-shared. Then generated libstdc++.so *would* be broken
(because of PR 48200). Then build GCC again w/o CXXFLAGS_FOR_TARGET=-flto, and
install the working libstdc++.so.
Or try to hack libstdc++ building system, use "-flto -ffat-lto-objects" to
compile .cc to .o, and use "-fno-lto" for *shared* library libstdc++.so.
(Maybe also other shared libraries of GCC).
I'm trying to resolve PR 48200, but no much progress now.
