[m-rev.] for review: Make link-time optimisation with gcc work.
Julien Fischer
jfischer at opturion.com
Tue Jan 28 15:24:34 AEDT 2020
On Tue, 28 Jan 2020, Peter Wang wrote:
> On Tue, 28 Jan 2020 15:12:46 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>>
>> Hi Peter,
>>
>> On Tue, 28 Jan 2020, Peter Wang wrote:
>>
>>> configure.ac:
>>> Add -flto to LINK_SHARED_OBJ and LINK_SHARED_OBJ_SH commands
>>> when LTO is enabled with gcc.
>>>
>>> Search for and use LTO-aware gcc-ar, gcc-ranlib and gcc-nm
>>> programs in place of the normal tools.
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 3e7e10c09..6dbee8860 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -5348,7 +5348,19 @@ if test "$mercury_cv_lto" = "yes"; then
>>> CFLAGS_FOR_LTO="-GL"
>>> LDFLAGS_FOR_LTO="-LTCG"
>>> ;;
>>> - gcc*|clang*)
>>> + gcc*)
>>> + CFLAGS_FOR_LTO="-flto"
>>> + LDFLAGS_FOR_LTO="-flto"
>>> + LINK_SHARED_OBJ="$LINK_SHARED_OBJ -flto"
>>> + LINK_SHARED_OBJ_SH="$LINK_SHARED_OBJ_SH -flto"
>>> + AC_CHECK_TOOL([GCC_AR], [gcc-ar], [])
>>> + AC_CHECK_TOOL([GCC_RANLIB], [gcc-ranlib], [])
>>> + AC_CHECK_TOOL([GCC_NM], [gcc-nm], [])
>>
>>
>> Is that going to work in situations where the gcc executable is not
>> named gcc. (For Homebrew, it is named gcc-9, gcc-8 etc.)
>> (We don't need to support that case now however.)
>
> I don't know. As long as gcc-ar etc. are still available without the
> version suffix, otherwise I assume they won't be found.
I don't know what they're named on that machine; I'll check this
evening.
Julien.
More information about the reviews
mailing list