考虑到我正在从源代码编译GCC + mpfr、gmp、mpc、libelf和binutils，这样更改优化标志是一个好主意吗？
CFLAGS="-O3" CXXFLAGS="-O3" ./configure
在配置GCC或其他软件时，您需要注意什么？
我有一个c2duo处理器。
编辑：我担心这些标志可能会改变这些程序/库的行为。
3个回答
4
您可以做两件事：
If you're natively bootstrapping, you can do a full, and complete profile guided bootstrap. This will build the compiler and dependencies with a bootstrapped compiler providing the third round with the profile information it can use to optimize itself. After
configure, domake profiledbootstrap. Note you can place the dependencies and stuff likke binutils and gdb inside the gcc source tree, and they should be built as well in the process.If you don't want to go through a long profiled bootstrap process, set
CFLAGS,CXXFLAGS,CFLAGS_FOR_TARGET,CXXFLAGS_FOR_TARGET, etc. at GCC configure time to:-O2 -flto -march=core2And set
LDFLAGSandLDFLAGS_FOR_TARGETto-flto
这将优化最多和最安全的内容。
请注意，所有这些麻烦可能只会在最终可执行文件中获得微小的加速。
- rubenvb
6
我不太明白关于包含 mpfr、gmp、mpc 和 binutils（也许还有 libelf？）源代码的事情。这是我的 gcc 压缩包的内容 http://pastebin.com/Ry6TBMLz 我应该把每个额外的文件夹放在根目录下还是 gcc 子文件夹下？ - user2485710
如果你将
gcc-4.8.1 提取出来，你应该能够添加 gcc-4.8.1/gmp 等等，让 GCC 构建系统也构建 GMP 等等。这并不是完全可靠的，但在 Linux 上可能仍然有效。 - rubenvb好的，但是这需要引导程序吗？还是只需在“./configure”后键入“make”即可立即工作？那么 libelf 呢？ - user2485710
GCC的configure中的这行代码告诉你哪些子目录的库可以在源码树中构建。
libelf就是其中的一部分。在configure之后执行make应该就可以了。你可能需要使用--with-gmp --with-mpfr --with-mpc --with-isl --with-cloog --with-libelf来避免使用系统库。 - rubenvb我尝试重新编译GCC，当使用将所用库的源代码直接添加到gcc根目录的系统时，它可以工作，但对于_host_tools_则不起作用。例如，我尝试添加一个带有相关源代码的
binutils目录，但似乎这并不起作用，这是正常的吗？我应该如何添加本地的binutils安装？我想提供一个与全局可用的不同的binutils安装。 - user2485710@user2485710 我从未解决过这个问题。也许可以通过配置binutils的
--with-sysroot=/usr和--prefix=/your/binutils/install/prefix来解决，然后在构建GCC之前将your/binutils/install/prefix/bin添加到PATH中。虽然它应该仍然有效... - rubenvb2
先衡量，再优化。在这种情况下，我首先会尝试使用原始编译器和默认配置设置（步骤0）编译gcc。
一旦我确定编译完成没有问题，那么就可以进行以下操作：
make distclean
首先，使用类似的编译器并测量使用该编译器编译所需的时间（步骤1）。
接着，安装新的gcc，并测量新的gcc（和其他工具）使用默认配置编译所需的时间（步骤2）。
然后，使用您喜欢的任何-O优化级别或其他非默认设置进行编译。一旦您获得了干净的编译结果，请执行“make distclean”，然后再次测量使用非默认设置的新默认设置gcc编译自身所需的时间（步骤3）。
现在，您拥有一个可以用于编译自身的-O3（或其他）gcc（步骤4），并以与其他步骤相同的方式进行测量。
最后，比较计时（确保您从每个编译之前都处于相同的基本状态）。您真正关心的部分是步骤2和步骤4，但步骤1和步骤3也可能提供信息。
请注意，这实际上只是衡量gcc（或其他编译器）能够编译自身的速度，如果您编写的代码与此非常不同，则您的效果可能会有所不同 - 但是您可以使用相同的技术来测量和比较各种优化级别在您经常编译的任何代码中的速度。
- D McKeon
2
好的 - 你的目标是什么？或者，权衡 - 你想要什么，你愿意放弃什么来得到它们？编译时间，运行时间，编译器可执行文件大小，程序可执行文件大小，swappiness等等？ - D McKeon
1@AudriusMeškauskas，但是由于上面答案中编译的代码本身就是GCC，编译速度表明了优化代码的性能如何。 - Jonathan Wakely
1
编辑：我担心这些标志会改变这些程序/库的行为。
理论上不应该，但有时确实会改变/破坏行为。
如果你想要确定，最好使用经过充分测试的默认设置。
请注意，如果其他值如-O1或-O3可以显著提高性能，那么这些设置已经成为标准并且已经被测试过了。
- Hennes
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
-O3可能会使代码变慢。通常建议使用-O2。 - jordanm-O3会使内联变得更加激进，从而导致代码膨胀。缓存失效率更高，需要从磁盘读取更多的代码...大多数情况下会更慢。Linux 内核一段时间以来一直使用-Os进行编译，因为这样更快... - vonbrand-O3编译几乎总是比使用-O2编译需要更长的时间，但由于通常只编译一次，所需时间并不重要。如下面的答案所说，为了更快的GCC，如果使用-O3可靠地使GCC更快，那么它将成为默认选项。使用基于配置文件的优化和/或LTO进行引导是获得更快GCC的更好方法。 - Jonathan Wakely