生产编译器如何在流控制上实现析构函数处理
How do production compilers implement destructor handling on flow control

在大多数情况下，析构函数调用可以与普通函数调用相同的方式处理。

较小的部分是处理EH。 我注意到MSC在“普通”代码中生成内联析构函数调用的混合，并且对于x86-64，创建单独的清理代码，其本身可能有也可能没有析构函数逻辑的副本。

IMO，最简单的解决方案是始终将非平凡的析构函数称为普通函数。

如果看起来可能出现优化，那么就像上面的其他内容一样处理上述调用：它是否适合其他所有内容？ 这样做会占用图像中太多的空间吗？ 等等..

前端可以在其输出AST中的每个可操作块的末尾向非平凡析构函数插入“调用”。

后端可以处理诸如普通函数调用之类的东西，将它们连接在一起，在某处创建一个大块o-析构函数调用逻辑并跳转到那个等等......

将函数链接到相同的逻辑似乎很常见。 例如，MSC倾向于将所有普通函数链接到相同的实现，析构函数或其他，优化与否。

这主要来自经验。 像往常一样，YMMV。

还有一件事：

EH清理逻辑往往像跳转表一样工作：对于给定的函数，您可以跳转到单个析构函数调用列表，具体取决于抛出异常的位置（如果适用）。

我不知道商业编译器如何提出代码，但假设我们忽略了异常[1]，我采取的方法是调用析构函数，而不是内联它。 每个析构函数都包含该对象的完整析构函数。 使用循环来处理数组的析构函数。

内联调用是一种优化，除非你“知道它得到回报”（代码大小与速度），否则你不应该这样做。

你将需要处理“封闭块中的破坏”，但假设你没有跳出块，那应该很容易。 跳出块（例如返回，中断等）意味着你必须跳转到一段代码来清理你所在的块。

[1]商业编译器具有基于“抛出异常的位置”的特殊表，以及为执行该清理而生成的一段代码 - 通常通过在每个清理块中具有多个跳转标签来对许多异常点重用相同的清理。

编译器使用两种方法的混合。 MSVC使用内联析构函数调用正常的代码流，并以相反的顺序清理代码块以用于早期返回和异常。 在正常流程中，它使用单个隐藏的本地整数来跟踪到目前为止的构造函数进度，因此它知道在早期返回时跳转到何处。 单个整数就足够了，因为范围总是形成一个树（而不是说为已经成功构建或未成功构建的每个类使用位掩码）。 例如，以下相当短的代码使用具有非平凡析构函数的类和一些随机返回在整个...

    ...
    if (randomBool()) return;
    Foo a;
    if (randomBool()) return;
    Foo b;
    if (randomBool()) return;

    {
        Foo c;
        if (randomBool()) return;
    }

    {
        Foo d;
        if (randomBool()) return;
    }
    ...

...可以在x86上扩展为如下所示的伪代码，其中构造函数进度在每个构造函数调用之后立即递增（有时通过多于一个到下一个唯一值）并在每个构造函数紧接之前递减（或“弹出”到更早的值）析构函数。 请注意，具有普通析构函数的类不会影响此值。

    ...
    save previous exception handler // for x86, not 64-bit table based handling
    preallocate stack space for locals
    set new exception handler address to ExceptionCleanup
    set constructor progress = 0
    if randomBool(), goto Cleanup0
    Foo a;
    set constructor progress = 1 // Advance 1
    if randomBool(), goto Cleanup1
    Foo b;
    set constructor progress = 2 // And once more
    if randomBool(), goto Cleanup2

    {
        Foo c;
        set constructor progress = 3
        if randomBool(), goto Cleanup3
        set constructor progress = 2 // Pop to 2 again
        c.~Foo();
    }

    {
        Foo d;
        set constructor progress = 4 // Increment 2 to 4, not 3 again
        if randomBool(), goto Cleanup4
        set constructor progress = 2 // Pop to 2 again
        d.~Foo();
    }

// alternate Cleanup2
    set constructor progress = 1
    b.~Foo();
// alternate Cleanup1
    set constructor progress = 0
    a.~Foo();

Cleanup0:
    restore previous exception handler
    wipe stack space for locals
    return;

ExceptionCleanup:
    switch (constructor progress)
    {
    case 0: goto Cleanup0; // nothing to destroy
    case 1: goto Cleanup1;
    case 2: goto Cleanup2;
    case 3: goto Cleanup3;
    case 4: goto Cleanup4;
    }
    // admitting ignorance here, as I don't know how the exception
    // is propagated upward, and whether the exact same cleanup
    // blocks are shared for both early returns and exceptions.

Cleanup4:
    set constructor progress = 2
    d.~Foo();
    goto Cleanup2;
Cleanup3:
    set constructor progress = 2
    c.~Foo();
    // fall through to Cleanup2;
Cleanup2:
    set constructor progress = 1
    b.~Foo();
Cleanup1:
    set constructor progress = 0
    a.~Foo();
    goto Cleanup0;
    // or it may instead return directly here

编译器当然可以重新排列这些块，无论如何它认为更有效，而不是将所有清理结束。 早期的返回可能会跳转到函数末尾的备用Cleanup1 / 2。 在64位MSVC代码上，异常通过表来处理，这些表将异常发生的指令指针映射到相应的代码清理块。

优化编译器正在转换已编译源代码的内部表示。

它通常构建基本块的定向（通常是循环）图。 构建此控制流图时，它会将调用添加到析构函数中。

对于GCC （它是一个免费的软件编译器 - 以及Clang / LLVM - 所以你可以研究它的源代码），你可能会尝试用-fdump-tree-all编译一些简单的C ++测试用例代码，然后看看它是在简化时完成的。 顺便说一句，您可以使用MELT自定义g++来探索其内部表示。

顺便说一句，我不认为你如何处理析构函数是重要的（请注意，在C ++中他们被隐式调用在语法上定义的地方，比如}其定义范围）。 这种编译器的大部分工作都在优化（然后，处理析构函数不是很相关;它们几乎就像其他程序一样）。