Using -flto in CXXFLAGS_FOR_TARGET

[U.Mutlu]

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.
>