noexcept,堆栈展开和性能

Question

以下来自Scott Meyers的新C++ 11书中的草稿(第2页,第7-21行)

展开调用堆栈和可能展开调用堆栈之间的区别对代码生成产生了惊人的巨大影响.在noexcept功能,优化不需要保持运行栈在unwindable状态,如有异常会向外传播的功能,也不是他们必须确保在noexcept函数对象在施工相反的顺序应该例外离开此功能被破坏.结果是更多的优化机会,不仅在noexcept函数的主体内,而且在调用函数的站点.这种灵活性仅适用于noexcept功能.具有"throw()"异常规范的函数缺少它,没有异常规范的函数也没有.

相比之下,部分5.4的"关于C++的性能技术报告"描述了"代码"和实施异常处理的"表"的方式.特别是,当没有抛出异常并且只有空间开销时,"table"方法被显示没有时间开销.

我的问题是这个 - 斯科特迈尔斯在谈论解散和可能解散的时候谈到了什么优化？为什么这些优化不适用throw()？他的评论是否仅适用于2006 TR中提到的"代码"方法？

Answer 1

有"没有"开销,然后没有开销.您可以通过不同方式考虑编译器:

• 它生成一个执行某些操作的程序.
• 它生成满足某些约束的程序.

TR表示在表驱动的appraoch中没有开销,因为只要不发生抛出就不需要采取任何操作.非特殊的执行路径直接进行.

但是,为了使表工作,非特殊代码仍然需要额外的约束.在任何异常可能导致其被破坏之前,需要对每个对象进行完全初始化,从而限制对可能抛出的调用的指令(例如,来自内联构造函数)的重新排序.同样,在任何可能的后续异常之前,必须完全销毁对象.

基于表的展开仅适用于遵循ABI调用约定的函数,具有堆栈帧.如果没有异常的可能性,编译器可以自由地忽略ABI并省略该帧.

以表格和单独的特殊代码路径形式的空间开销(又称膨胀)可能不会影响执行时间,但它仍然会影响下载程序并将其加载到RAM中所花费的时间.

这都是相对的,但noexcept会使编译器有些松懈.

Answer 2

noexcept和之间的区别throw()是,在throw()异常堆栈的情况下仍然展开并且调用析构函数,因此实现必须跟踪堆栈(参见15.5.2 The std::unexpected() function标准).

相反,std::terminate()不要求堆栈被展开(15.5.1声明它是实现定义的,无论堆栈是否在std::terminate()被调用之前被展开).

GCC似乎真的没有解开堆栈noexcept:演示
虽然clang仍然解开:演示

(你可以在演示中评论f_noexcept()和取消注释f_emptythrow(),看看throw()GCC和clang都能解开堆栈)

Answer 3

请看以下示例:

#include <stdio.h>

int fun(int a) {

  int res;
  try
  {
    res = a *11;
    if(res == 33)
       throw 20;
  }
  catch (int e)
  {
    char *msg = "error";
    printf(msg);
  }
  return res;
}

int main(int argc, char** argv) {
  return fun(argc);
}

从编译器的角度来看,作为输入传递的数据是不可预见的,因此即使使用-O3优化来完全忽略调用或异常系统也不能做出任何假设.

在LLVM IR中,fun函数大致翻译为

define i32 @_Z3funi(i32 %a) #0 {
entry:
  %mul = mul nsw i32 %a, 11 // The actual processing
  %cmp = icmp eq i32 %mul, 33 
  br i1 %cmp, label %if.then, label %try.cont // jump if res == 33 to if.then

if.then:                                          // lots of stuff happen here..
  %exception = tail call i8* @__cxa_allocate_exception(i64 4) #3
  %0 = bitcast i8* %exception to i32*
  store i32 20, i32* %0, align 4, !tbaa !1
  invoke void @__cxa_throw(i8* %exception, i8* bitcast (i8** @_ZTIi to i8*), i8* null) #4
          to label %unreachable unwind label %lpad

lpad:                                             
  %1 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*)
          catch i8* bitcast (i8** @_ZTIi to i8*)
 ... // also here..

invoke.cont:                                      
  ... // and here
  br label %try.cont

try.cont:        // This is where the normal flow should go
  ret i32 %mul

eh.resume:                                        
  resume { i8*, i32 } %1

unreachable:                                    
  unreachable
}

你可以看到代码路径,即使在正常控制流(没有例外)的情况下直截了当,现在由同一函数中的几个基本块分支组成.

确实,在运行时几乎没有成本关联,因为你支付你使用的费用(如果你不扔,没有额外的事情发生),但有多个分支也可能会损害你的表现,例如

• 分支预测变得更难
• 套准压力可能会大幅增加
• [其他]

当然,您无法在正常控制流和着陆点/异常入口点之间运行直通分支优化.

异常是一种复杂的机制,noexcept即使在零成本EH中也极大地促进了编译器的生命.

编辑:在说明noexcept符的特定情况下,如果编译器无法" 证明 "您的代码没有抛出,std::terminate则设置EH(具有依赖于实现的详细信息).在这两种情况下(代码都不抛出和/或无法证明代码没有抛出),所涉及的机制更简单,编译器受限制更少.无论如何,你并没有真正noexcept用于优化的原因,它也是一个重要的语义指示.