【问题标题】:GCC seemingly misses simple optimizationGCC 似乎错过了简单的优化
【发布时间】:2019-02-18 14:24:31
【问题描述】:

我正在尝试引入一个具有三元运算符语义的通用函数:E1 ? E2 : E3。我看到编译器能够根据三元运算符的E1 条件消除E2E3 之一的计算。然而 GCC 在ternary 函数调用的情况下错过了这种优化(即使E2/E3 没有副作用)。

在下面的列表中,函数ternary 的行为类似于三元运算符。然而,GCC 对函数 f 发出了潜在的大量调用,这对于某些输入值似乎可以被消除(对于三元运算符的确切做法),因为 f 是用纯属性声明的 - 请查看生成的汇编代码的 godbolt 链接由 GCC 提供。

在 GCC 中是否可以改进(优化空间)或 C++ 标准是否明确禁止此类优化?

// Very heavy function
int f() __attribute__ ((pure));

inline int ternary(bool cond, int n1, int n2) {
    return cond ? n1 : n2;
}

int foo1(int i) {
    return i == 0 ? f() : 0;
}

int foo2(int i) {
    return ternary(i == 0, f(), 0);
}

使用-O3 -std=c++11 列出程序集:

foo1(int):
  test edi, edi
  jne .L2
  jmp f()
.L2:
  xor eax, eax
  ret
foo2(int):
  push rbx
  mov ebx, edi
  call f()
  test ebx, ebx
  mov edx, 0
  pop rbx
  cmovne eax, edx
  ret

https://godbolt.org/z/HfpNzo

【问题讨论】:

  • 它与__attribute__ ((const))“工作”。
  • @melpomene: __attribute__ ((const)) 表示该函数甚至无法读取全局变量,而__attribute__((pure)) 表示它可以读取全局变量但没有副作用。 (gcc.gnu.org/onlinedocs/gcc/…)。所以我认为不优化调用是一个错过的优化,因为我们知道它没有副作用。它适用于 foo1 的情况,但这是因为 C 抽象机不会在三元的未使用侧评估 f()
  • @eXX:您应该将其报告为 GCC 的 bugzilla 上的关键字 =missed-optimization 错误。 gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc.
  • 嘿。如果我将foo1 更改为int t = f(); return i == 0 ? t : 0;,GCC 不会对其进行优化(它总是调用f),但随后会将foo2 编译为jmp foo1
  • 让这件事变得棘手的一件事是,绝对没有迹象表明函数调用很昂贵,并且有 表明 不是调用函数很昂贵:这需要一个额外的分支。

标签: c++ gcc assembly optimization


【解决方案1】:

我看到编译器能够根据三元运算符的 E1 条件(只要 E2/E3 没有副作用)消除 E2 或 E3 之一的计算。

编译器不会消除它;它只是从一开始就从未将其优化为cmovC++ 抽象机评估三元运算符未使用的一面。

int a, b;
void foo(int sel) {
    sel ? a++ : b++;
}

像这样编译 (Godbolt):

foo(int):
    test    edi, edi
    je      .L2                # if(sel==0) goto
    add     DWORD PTR a[rip], 1   # ++a
    ret
.L2:
    add     DWORD PTR b[rip], 1   # ++b
    ret

如果两个输入都没有任何副作用,则三元运算符只能优化为 asm cmov。否则它们不完全等价。


在 C++ 抽象机(即 gcc 优化器的输入)中,您的 foo2 总是调用 f(),而您的 foo1 不会。 foo1 编译并不奇怪它的方式。

要使 foo2 以这种方式编译,它必须优化对 f() 的调用。总是调用它来为 ternary() 创建一个 arg。


这里有一个错过的优化,您应该在 GCC 的 bugzilla 上报告(使用 missed-optimization 关键字作为标签)。 https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc

int f() __attribute__ ((pure)); 的调用应该可以被优化掉。它可以读取全局变量,但不能有任何副作用。 (https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html)

正如@melpomene 在 cmets 中发现的那样,int f() __attribute__ ((const)); 确实为您提供了您正在寻找的优化。 __attribute__((const)) 函数甚至不能读取全局变量,只能读取它的参数。 (因此没有参数,它必须总是返回一个常量。)

HVD 指出 gcc 没有f() 的任何费用信息。即使它可以优化了对((pure)) f()((const)) f 的调用,也许它没有因为它不知道它比条件分支更昂贵?可能使用配置文件引导的优化进行编译会说服 gcc 做某事?

但是考虑到它在foo2 中对((const)) f 的调用是有条件的,gcc 可能只是不知道它可以优化对((pure)) 函数的调用?也许它只能对它们进行 CSE(如果没有编写全局变量),但不能完全远离基本块进行优化?或者,当前的优化器可能无法利用。就像我说的,看起来像是一个错过选择的错误。

【讨论】:

    猜你喜欢
    • 2019-03-02
    • 1970-01-01
    • 2013-03-20
    • 1970-01-01
    • 2022-01-15
    • 2018-03-30
    • 1970-01-01
    • 2014-04-19
    • 2018-10-04
    相关资源
    最近更新 更多