Gcc 如何知道哪些代码被优化了？

是否有一种方法可以在编译期间或编译之后获取有关代码哪些部分已优化的信息，但不查看程序集或执行代码

如果一个大的代码块被优化了，那么马上知道就好了

gcc -S

将输出本应传递给汇编程序（并最终链接到可执行文件）的汇编代码。如果您眯着眼睛看正确的方向（并且有耐心），您可以从中向后看，以确认给定的代码位是否已实际包含在可执行文件中，或者是否已被优化

gcc -S

---

显然，除非你怀疑正在发生什么事情，否则你不会去做，因为这需要时间和精力…

对不起，但是你的期望与编译器实际做的并不相符。无论您是试图查找死代码还是查找导致应该运行的代码被跳过的错误，编译器都不能以易于阅读的形式提供这些信息

有了一个将每一行源代码翻译成一系列机器指令的编译器，编译器可以很容易地告诉您它没有包含任何与特定行对应的内容。当然，它不能告诉你一行是否被翻译成了机器指令，但这些机器指令实际上永远不会被执行——代码的可访问性是——但我不认为这就是你想要的

问题是，现代优化编译器要比这复杂得多。一段代码通常在不同的假设下被复制和编译多次（专门化、部分求值、循环展开等等）。或者，相反，代码片段可以合并在一起（函数内联，…）。源代码和机器代码之间没有简单的对应关系。（这就是为什么调试器有时难以报告二进制指令的确切源代码位置。）

如果一大块代码被优化了，那可能仅仅是因为它是许多专门化副本中的一个，而这种专门化从未发生过（例如，

x==0

和

x！=0

有单独的代码，

y==0

和

y！=0

有单独的代码，

x

和

y

永远不会同时为0，因此

x==0&&y==0

分支最终被删除）它可能是由编译时条件指令生成的，例如编译器优化的C宏；这种情况在C代码中经常发生，如果编译器报告所有此类实例，将产生大量误报

---

获取潜在未使用代码或可疑程序代码的有用报告（可能表明存在错误）需要一种与编译器不同的静态分析。有一些工具可以做到这一点，但它们通常不是将源代码转换为优化机器代码的工具。使静态分析工具不要经常检测到潜在的问题以使其变得有用，也不要产生太多的误报，使它们实际上无法使用，这并不容易。

我知道-S，但我希望有一个更简单的解决方案。为什么知道这一点会很好？这是优化器的工作，优化大块代码。它删除了复杂的抽象，helper方法，人类编写的所有东西都是为了让代码更易于阅读和推理。为什么你觉得需要对优化器进行二次猜测？你真的有问题吗？@Cody Gray它可能会暴露我正在编译的代码（甚至编译器）中的错误，这会满足我的好奇心：）