局部变量与类变量编译器优化；有效与无效

Question

我有一个代码示例，其中当结构为类变量时，直接优化不起作用，但作为局部变量起作用；我想知道：为什么类变量公式没有发生优化？

我的示例代码的目的是拥有一个在构造时启用或禁用并可能在其生命周期内更改的类。我希望，当对象在其整个生命周期内被禁用时，编译器将优化在启用对象时有条件执行的所有代码。

具体来说，我有一个 std::ofstream 我只想在“启用”时写入。禁用时，我希望跳过所有格式化输出。 （我真正的类有它自己的、不平凡的消息格式。）

我发现当我将其表述为一个类时，我没有得到我期望的优化。但是，如果我将代码全部复制为局部变量，我确实会看到预期的行为。

此外，我发现，如果我不在示例类方法主体中的任何位置进行 std::ofstream 调用，例如“open”、“exceptions”或“clear”，我也会获得预期的优化。 （但是，我的设计需要对 std::ofstream 进行此类调用，所以对我来说这是一个没有实际意义的问题。）下面的代码使用 MACRO DISABLE_OPEN_OFSTREAM_AFTER_CONSTRUCTOR 来允许尝试这种情况。

我的示例代码使用“asm”表达式将注释插入到生成的汇编代码中。如果有人在汇编中检查编译器的输出，我希望“disabled-test”注释之间不会有汇编。我正在观察“类禁用测试”注释之间的汇编，但“本地禁用测试”注释之间没有汇编。

输入 C++ 代码：

#include <fstream> // ofstream

#define DISABLE_OPEN_OFSTREAM_AFTER_CONSTRUCTOR 0

class Test_Ofstream
{
public:
    Test_Ofstream( const char a_filename[],
                   bool a_b_enabled )
    #if DISABLE_OPEN_OFSTREAM_AFTER_CONSTRUCTOR
        : m_ofstream( a_filename ),
          m_b_enabled( a_b_enabled )
    {
    }
    #else
        : m_ofstream(),
          m_b_enabled( a_b_enabled )
    {
        m_ofstream.open( a_filename );
    }
    #endif

    void write_test()
    {
        if( m_b_enabled )
        {
            m_ofstream << "Some text.\n";
        }
    }

private:
    std::ofstream m_ofstream;
    bool m_b_enabled;
};

int main( int argc, char* argv[] )
{
    {
        Test_Ofstream test_ofstream( "test.txt", true );
        asm( "# BEGIN class enabled-test" );
        test_ofstream.write_test();
        asm( "# END class enabled-test" );
    }

    {
        Test_Ofstream test_ofstream( "test.txt", false );
        asm( "# BEGIN class disabled-test" );
        test_ofstream.write_test();
        asm( "# END class disabled-test" );
    }

    {
        bool b_enabled = true;
        #if DISABLE_OPEN_OFSTREAM_AFTER_CONSTRUCTOR
        std::ofstream test_ofstream( "test.txt" );
        #else
        std::ofstream test_ofstream;
        test_ofstream.open( "test.txt" );
        #endif
        asm( "# BEGIN locals enabled-test" );
        if( b_enabled )
        {
            test_ofstream << "Some text.\n";
        }
        asm( "# END locals enabled-test" );
    }

    {
        bool b_enabled = false;
        #if DISABLE_OPEN_OFSTREAM_AFTER_CONSTRUCTOR
        std::ofstream test_ofstream( "test.txt" );
        #else
        std::ofstream test_ofstream;
        test_ofstream.open( "test.txt" );
        #endif
        asm( "# BEGIN locals disabled-test" );
        if( b_enabled )
        {
            test_ofstream << "Some text.\n";
        }
        asm( "# END locals disabled-test" );
    }

    return 0;
}

输出汇编代码：

##### Cut here. #####
#APP
# 53 "test_ofstream_optimization.cpp" 1
        # BEGIN class disabled-test
# 0 "" 2
#NO_APP
        cmpb        $0, 596(%esp)
        je  .L22
        movl        $.LC1, 4(%esp)
        movl        %ebx, (%esp)
.LEHB9:
        call        _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
.LEHE9:
.L22:
#APP
# 55 "test_ofstream_optimization.cpp" 1
        # END class disabled-test
# 0 "" 2
#NO_APP
##### Cut here. #####
#APP
# 116 "test_ofstream_optimization.cpp" 1
        # BEGIN locals disabled-test
# 0 "" 2
# 121 "test_ofstream_optimization.cpp" 1
        # END locals disabled-test
# 0 "" 2
#NO_APP
##### Cut here. #####

我意识到这可能与我正在使用的编译器有关，即： g++-4.6 (Debian 4.6.1-4) 4.6.1;编译器标志：-Wall -S -O2。然而，这似乎是一个如此简单的优化，我发现很难相信它可能是编译器搞砸了。

非常感谢任何帮助、见解或指导。

Answer 1

很简单。当您直接将代码编写为局部变量时，代码将被内联，编译器将执行常量折叠。当您位于类作用域中时，代码不会内联，并且 m_b_enabled 的值未知，因此编译器必须执行调用。为了证明代码在语义上是相等的并执行此优化，不仅必须内联该调用，还必须内联对类的每次访问。编译器很可能认为内联类不会产生足够的好处。编译器还可以选择不内联代码，因为它们不知道如何内联，而内联 asm 表达式正是可能导致它们这样做的类型，因为编译器不知道如何处理你的汇编代码。

通常，您会放置一个断点并检查反汇编。无论如何，这就是我在 Visual Studio 中要做的事情。任何类型的内联汇编器都可能对优化器造成很大的损害。

当我删除汇编器表达式时，Visual Studio 内联了代码，并且立即没有执行优化。堆叠优化过程的问题在于，您永远无法获得正确的顺序来找到所有潜在的优化。

Answer 2

正如你所说，这取决于编译器。但我的猜测：

优化器可以证明没有其他代码可以修改对象 bool b_enabled，因为它是本地的，并且您永远不会获取它的地址或绑定对它的引用。本地版本很容易优化。

当 DISABLE_OPEN_OFSTREAM_AFTER_CONSTRUCTOR 为 true 时，Test_Ofstream 构造函数：

• 调用构造函数 ofstream(const char*)
• 成员 m_b_enabled

初始化 初始化 test_ofstream.m_b_enabled 和测试之间没有任何操作，这种优化只是有点棘手，但听起来像g++ 仍然可以管理它。

当 DISABLE_OPEN_OFSTREAM_AFTER_CONSTRUCTOR 为 false 时，Test_Ofstream 构造函数：

• 调用 ofstream 默认构造函数
• 初始化成员 m_b_enabled
• 调用 m_ofstream .open(const char*)

优化器不允许假设 ofstream::open 不会改变test_ofstream.m_b_enabled。我们知道不应该，但理论上非内联库函数可以找出包含“this”参数的完整对象 test_ofstream ，并以这种方式修改它。