Gentoo LDFLAGS действительно нужны оптимизации?

3986
user2868193

Я использую Gentoo Linux .

Вот мой набор инструментов:

sys-kernel/linux-headers-3.9 sys-devel/binutils-2.23.1 USE="cxx nls zlib -multislot -multitarget -static-libs {-test} -vanilla" sys-devel/gcc-4.7.3-r1:4.7 USE="cxx fortran gtk lto mudflap (multilib) nls nptl openmp (-altivec) -doc (-fixed-point) -gcj -go -graphite (-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++ -objc-gc -regression-test -vanilla" sys-libs/glibc-2.17:2.2 USE="(multilib) -debug -gd (-hardened) -nscd -profile (-selinux) -suid -systemtap -vanilla"

Вот мои CFLAGS:

$ cat /etc/portage/make.conf

CFLAGS="-march=core-avx-i -mtune=core-avx-i -O2 -pipe -flto" CXXFLAGS="$"  CHOST="x86_64-pc-linux-gnu" # etc...

Весь мир построен на LTO, за исключением нескольких пакетов:

$ cat /etc/portage/package.env

dev-lang/perl no-lto dev-libs/elfutils no-lto dev-lang/spidermonkey no-lto dev-libs/glib no-lto sys-devel/llvm no-lto media-libs/mesa no-lto media-libs/alsa-lib no-lto sys-apps/preload no-lto app-text/aspell no-lto app-text/rarian no-lto sys-power/upower no-lto net-libs/farstream no-lto dev-python/notify-python no-lto x11-libs/wxGTK no-lto media-video/avidemux no-lto media-gfx/inkscape no-lto x11-base/xorg-server no-lto x11-drivers/xf86-video-intel no-lto net-libs/webkit-gtk no-lto mail-client/thunderbird no-lto

$ cat /etc/portage/env/no-lto

CFLAGS="$ -fno-lto" CXXFLAGS="$ -fno-lto" LDFLAGS="$ -fno-lto"

В некоторых блогах я заметил, что авторы, устанавливающие LDFLAGS в их файле make.conf, я этого не делал.

Операционная система устанавливает эти LDFLAGS в соответствии с выбранным профилем:

$ emerge --info | grep LDFLAGS

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

Разработчики и сопровождающие Gentoo не рекомендуют менять их

Я хотел бы установить эти строки в моем make.confфайле, а затем перестроить toolchain и world:

CFLAGS="-march=core-avx-i -mtune=core-avx-i -O2 -pipe -flto -Wl,-flto" LDFLAGS="-Wl,-flto -Wl,-O2"

Будет ли разница в производительности / стабильности?

Стоят ли эти различия времени, необходимого для перекомпиляции всего мира?

Я хотел бы услышать предложения, объяснения, лучшие практики от опытных пользователей / сопровождающих / программистов / администраторов Gentoo ...

Заранее большое спасибо!

3
По вашей ссылке они действительно не побуждают вас менять их. Они просто говорят, что это не обязательно. Также вы их не меняли. Выходные данные `emerge --info` - это то, что уже установлено, поэтому установка этого же значения явно ничего не меняет. Этот вопрос может быть больше по теме на unix.stackexchange.com, поэтому не смущайтесь, когда он перемещается туда (учетные записи с обоих сайтов объединяются, если вы регистрируетесь с одинаковой аутентификацией), Tim 10 лет назад 0
@Tim Вы когда-нибудь понимали, что `--as-required` автоматически заменяется на` -Wl, -flto -Wl, -O2`? user2868193 10 лет назад 0
Извините, что пропустил эту разницу. Вы меняете что-то их. Кстати: разве вы не должны также включить LTO в LDFLAGS? Tim 10 лет назад 0
Кстати, `-march` является надмножеством` -mtune`. Иметь и то, и другое бессмысленно. Daniel B 9 лет назад 0

2 ответа на вопрос

1
robbat2

You don't need to change your CFLAGS there to add -Wl,-lfto; unless there are some packages that are mistakenly using CFLAGS for linking, it won't help (and those packages should be reported to bugzilla).

You do however need to add -flto to LDFLAGS to get full benefit of LTO. LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-flto"

You will not actually get LTO performance until you have the addition in your LDFLAGS, so yes, you will need to recompile anything that did not explicitly enable/disable LTO itself.

1
anonymous

When doing LTO builds, it is important to pass the same optimization flags to both the compiler and the LTO linker. This does not mean just -On, but actually all other optimization flags.

When you build the final binary and link using the compiler itself in a single pass, it all works. If you do it in two passes (libtool, I am looking at you!) then all hell breaks loose.

So, yes, it is exactly right to enforce that everything optimization-related in CFLAGS and CXXFLAGS is also present in LDFLAGS. And they must match for the results to be correct, the fact that the gcc documentation seems to imply otherwise is a reported bug against gcc.

Whether you need to enforce it by doing nothing special to LDFLAGS, or duplicating them in LDFLAGS depends on the build system used by the package, and whether late-linking by libtool and its ilk will happen.

Похожие вопросы