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

Question

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

我的示例代码的目的是让 class 在构造时启用或禁用，并且可能在其生命周期内更改。 我希望，当 object 在其整个生命周期内被禁用时，编译器会优化掉所有在启用 object 时有条件地执行的代码。

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

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

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

我的示例代码使用“asm”表达式将注释插入到生成的汇编代码中。 如果在汇编中检查编译器的 output，我希望在“禁用测试”注释之间没有汇编。 我正在观察“class disabled-test”注释之间的组装，但“locals 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;
}

output 汇编代码：

##### 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

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

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

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

Answer 2

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

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

当DISABLE_OPEN_OFSTREAM_AFTER_CONSTRUCTOR为真时， 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 。 我们知道它不应该，但理论上非内联库 function 可以找出包含其“this”参数的完整 object test_ofstream ，并以这种方式修改它。