c++ - 编译器如何使用编译器生成的临时文件确定函数所需的堆栈大小？

Question

考虑以下代码:

class cFoo {
    private:
        int m1;
        char m2;
    public:
        int doSomething1();
        int doSomething2();
        int doSomething3();
}

class cBar {
    private:
        cFoo mFoo;
    public:
        cFoo getFoo(){ return mFoo; }
}

void some_function_in_the_callstack_hierarchy(cBar aBar) {
    int test1 = aBar.getFoo().doSomething1();
    int test2 = aBar.getFoo().doSomething2();
    ...
}

在调用 getFoo() 的行中，编译器将生成 cFoo 的临时对象，以便能够调用 doSomething1()。 编译器是否重用用于这些临时对象的堆栈内存？ “some_function_in_the_callstack_hierarchy”的调用会保留多少堆栈内存？它是否为每个生成的临时文件保留内存？

我的猜测是编译器只为 cFoo 的一个对象保留内存，并将为不同的调用重用内存，但是如果我添加

    int test3 = aBar.getFoo().doSomething3();

我可以看到“some_function_in_the_callstack_hierarchy”所需的堆栈大小要大得多，这不仅仅是因为额外的本地 int 变量。

另一方面，如果我再替换

cFoo getFoo(){ return mFoo; }

带有引用(仅用于测试目的，因为返回对私有(private)成员的引用是不好的)

const cFoo& getFoo(){ return mFoo; }

它需要的堆栈内存比一个 cFoo 的大小要少得多。

所以对我来说，编译器似乎为函数中每个生成的临时对象保留了额外的堆栈内存。但这将是非常低效的。 谁能解释一下？

Answer 1

optimizing compiler正在将您的源代码转换为某种内部表示，并对其进行规范化。

与 free software编译器(如 GCC 和 Clang/LLVM )，您可以查看该内部表示(至少通过修补编译器代码或在某些调试器中运行它)。

顺便说一句，有时，临时值甚至不需要任何堆栈空间，例如因为它们已经过优化，或者因为它们可以放在寄存器中。而且他们经常会在当前调用帧中重用一些不需要的槽。此外(特别是在 C++ 中)很多(小)函数是 inlined - 就像你的 getFoo 可能是 - (所以他们自己没有任何调用框架)。最近的 GCC 甚至有时 能够tail-call优化(本质上，重用调用者的调用框架)。

如果您使用 GCC(即 g++)编译，我建议您使用 optimization options和 developer options (和其他一些)。也许使用 also -Wstack-usage=48(或其他一些值，以每个调用帧的字节数为单位)和/或 -fstack-usage

首先，如果您可以阅读汇编代码，请使用 g++ -S -fverbose-asm -O yourcode.cc 编译 yourcode.cc 并查看发出的 你的代码.s

^{(不要忘记使用优化标志，所以将 -O 替换为 -O2 或 -O3 .. ..)}

然后，如果你更好奇编译器是如何优化的，试试 g++ -O -fdump-tree-all -c yourcode.cc 你会得到很多所谓的“转储文件”，其中包含与 GCC 相关的内部表示的部分文本呈现。

如果你更好奇，看看我的GCC MELT尤其是它的 documentation页面(包含很多幻灯片和引用资料)。

So for me it seems that the compiler reserves extra stack memory for every generated temporary object in the function.

当然不是，在一般情况下(当然假设您启用了一些优化)。即使保留了一些空间，它也会很快被重新使用。

^{顺便说一句:请注意，C++11 标准并未提及堆栈。人们可以想象一些 C++ 程序在不使用任何堆栈的情况下编译(例如，整个程序优化检测一个没有递归的程序，其堆栈空间和布局可以被优化以避免任何堆栈。我不知道任何这样的编译器，但我知道编译器可以很聪明....)}