代码优化什么时候发生？

Question

昨天，我去面试了。他们问我代码优化什么时候发生？ 说，

int abc;//Global variable
abc = 3;
if(abc == 3)
{
  printf("abc will be always 3");
}
else
{
  printf("This will never executed");
}

现在的问题是优化何时发生？ A...在运行时 B...在编译时。 我在编译时回答...对我来说，我认为编译器在编译时检查 volatile 关键字。如果变量未声明为 易失性，那么它会优化代码。但是，当编译器知道这一点时，这个变量永远不会是 3 以外的值？ 如果是在运行时，那么编译器什么时候知道变量永远不会是 3 以外的值？因为如果这部分代码执行后变量要改变。请解答我的疑惑

Answer 1

C 代码通常使用静态（又称提前）编译进行编译。代码一旦离开编译器就被固定下来；它不能在运行时改变。

这与使用即时编译的语言形成对比，例如爪哇。在那里，优化几乎可以在程序运行时随时发生。

Answer 2

大多数代码优化不能在运行时发生，至少不是你的意思。代码在执行过程中无法更改以反映一组新的或不同的变量，这只会造成绝对的混乱。

在运行时可以做的是通过代码选择最佳路径，但这主要必须手动完成，以便创建单独的路径、早期退出、分支等以允许优化。

像这样的代码，正如所写的，允许编译时优化，因为编译器可以检查 abc 的任何可能的替代值，如果没有找到，则优化调用。然而，搜索的范围极大地影响了这种情况是否会发生，而编译器设置也会影响这一点。

如果编译器只是天真地优化单个目标文件，并且您的第二行位于打印部分的另一个文件中，那么它可能无法保证 abc 不会更改，因此不会完全能够优化这一点。无论变量的使用如何，这都取决于编译器设置的激进程度以及是否允许它们丢弃死分支，或者是否会考虑这样做。优化大小可能比速度更有可能删除分支，但中/高设置可能会以任何方式实现（如果可能）。

大多数现代编译器都有一个整体程序优化选项，它将大部分优化延迟到链接器阶段。这允许它搜索整个程序，可能会发现 abc 从未在其他任何地方更改或使用，并从条件中删除变量和失败分支。整个程序优化比针对每个对象单独优化要有效得多，因为它可以允许更准确的搜索。

在编译器无法修剪死代码的情况下，您可以提示它（最近的构造，例如 constexpr 可以帮助实现这一点）或自己添加优化。它可以很简单，只需将最有可能的路径放在前面，并在 else 之前包含一个 return，从而避免 CPU 进行跳转。这种微优化不太可能是必要的，尤其是在像这样的简单示例中，其中 if 本身就已经进行了大量优化。

Answer 3

不回答问题，但给出编译时优化的示例。当要求时，gcc 会优化代码。 -O（优化）选项可以实现不同级别的优化。它可以用作-O1、-O2 和-O3。 gcc 手册页准确地描述了每个级别的含义。

-S 选项将 C 转换为汇编并保存在 .s 文件中。

test.c

#include <stdio.h>

int abc;//Global variable

void main()
{
    abc = 3;
    if(abc == 3)
        printf("abc will be always 3");
    else
        printf("This will never executed");
}

在没有 gcc 优化的情况下，两个字符串出现在汇编代码中。

$ gcc -S test.c;cat test.s

    .file   "test.c"
    .comm   abc,4,4
    .section    .rodata
.LC0:
    .string "abc will be always 3"
.LC1:
    .string "This will never executed"
    .text
    .globl  main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movl    $3, abc(%rip)
    movl    abc(%rip), %eax
    cmpl    $3, %eax
    jne .L2
    movl    $.LC0, %eax
    movq    %rax, %rdi
    movl    $0, %eax
    call    printf
    jmp .L1
.L2:
    movl    $.LC1, %eax
    movq    %rax, %rdi
    movl    $0, %eax
    call    printf
.L1:
    popq    %rbp
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
    .ident  "GCC: (GNU) 4.6.1 20110908 (Red Hat 4.6.1-9)"
    .section    .note.GNU-stack,"",@progbits

在没有 gcc 1 级优化的情况下，只有一个字符串被翻译成汇编< /strong>

$ gcc -O1 -S test.c;cat test.s

    .file   "test.c"
    .section    .rodata.str1.1,"aMS",@progbits,1
.LC0:
    .string "abc will be always 3"
    .text
    .globl  main
    .type   main, @function
main:
.LFB11:
    .cfi_startproc
    subq    $8, %rsp
    .cfi_def_cfa_offset 16
    movl    $3, abc(%rip)
    movl    $.LC0, %edi
    movl    $0, %eax
    call    printf
    addq    $8, %rsp
    .cfi_def_cfa_offset 8
    ret
    .cfi_endproc
.LFE11:
    .size   main, .-main
    .comm   abc,4,4
    .ident  "GCC: (GNU) 4.6.1 20110908 (Red Hat 4.6.1-9)"
    .section    .note.GNU-stack,"",@progbits

Answer 4

在编译时:)

（原则上这取决于编译器等）

Answer 5

我不太熟悉编译器如何优化代码，但是我知道从您那里的代码中，编译器可以推断出 abc 永远不会被更改。这意味着它可以完全删除if语句，只调用第一个printf函数。

然后在运行时，就没有太多优化了，因为代码非常简单。如果abc要改变，那么显然if不能被省略，但是，在运行时，CPU上的分支预测之类的东西会尝试预测正在采取的代码路径。这也可以被认为是一种优化形式。

注意：我没有声称这就是发生的情况，但我可以看到编译器可能会在积极的优化设置中以这种方式进行优化。

Answer 6

我想知道他们是在寻找一个答案还是几个可能的答案。

通常，编译器在运行时不会执行任何操作。编译器二进制文件及其组件不需要出现在运行时环境中（对于 C 语言）。

消除这种死分支的优化类型将使用某些技术来编写优化编译器。请参阅 Muchnik 的有关编译器的书。使用的技术可能涉及创建基本块的有向图，然后使用以下之一：

• def-use 分析
• 静态单一分配 (ssa) 分析
  随着
• 常数传播（将 if 转换为 if(3==3)
  然后
• 消除常量表达式
  然后
• 死代码/死分支删除

另一方面，某些编译器可能无法在优化期间进行足够的计算来删除它。

在这种情况下，如果您在具有分支预测的芯片上运行代码，芯片将“学习”预测第一个分支，并有利地缓存（获取）该分支。但这不是编译器机制，通常不称为优化。

Answer 7

最简单的答案：
代码优化发生在撰写本文时。

简单回答：
也许，考虑到范围，它取决于编译器。

硬答案：
考虑到全局范围，编译器应该保留它，并假设它可以在文件的其他地方访问。多次通过可以优化它。如果编译器不认为它对文件是静态的（想想具有平面内存模型的系统），那么全局就是真正的全局，并且假设应该是任何可能改变该值的东西。这就是为什么要避免全局变量，除非意图确实是全局访问。

根据处理器的不同，分支预测参数将适用，但主要是编译时间或根本不适用。

ps：我真的很不喜欢这样的面试问题。