编译器会优化 malloc/free 或 new/delete 对到 alloca答案

【问题标题】：Will Compiler optimize malloc/free or new/delete pair into alloca编译器会优化 malloc/free 或 new/delete 对到 alloca
【发布时间】：2012-05-12 06:06:08
【问题描述】：

有没有成熟的 C/C++ 编译器，能够优化malloc/free（或new/delete）对信息alloca？换句话说，从基于堆的内存转换为基于堆栈的内存（仅适用于某些有限的情况）。

当两个函数在同一个函数中时（甚至在{}的同一块中），这种优化可能只允许对malloc/free，并且每次调用malloc时都会调用free。另外，让我们考虑一下指向 malloced 内存的指针没有保存在某个全局变量中。

那么，GCC/LLVM+clang/Intel 编译器会转换这样的代码块吗：

{
   char *carray;
   carray = malloc(100);          // or malloc(N)
   // some string-like work with carray
   free(carray);
}

进入

{
    char*carray;
    carray = alloca(100);  // or if(N<const1) carray=alloca(N);else carray=malloc(N)
    // the same work
    // nothing                       // or if(N>=const1) free(carray)
}

这种转换可能对每个程序都不是很有用，但我认为，可能会有一些特殊的编译器选项。

PS (update1) 我们可以将讨论仅限于编译器知道 malloc 和 free 来自 libc (stdlib) 的情况

【问题讨论】：

一年前 llvm 列表中的一个人 said no 和另一个人 said yes 并指向 actual code
我认为 malloc 不是内在的。而且这样做非常危险，因为编译器没有关于运行时堆栈大小的信息。
如果调用编译器看不到定义的任何其他函数并传递 malloc 的结果，则转换是不安全的：该函数可能将指针存储在某处，然后通过longjmp 跳过空闲（通常是 C）或异常（C++）。记住这一点，我怀疑这种转换并不像你想象的那么有用。
@osgx：“实际代码”与一个 malloc/free 对相关，其中分配的内存根本没有使用（但指针可能与 null 进行比较）。你说的是不同的东西，一个 malloc/free 对，在其中访问分配的内存。
@osgx '其他人说是'对另一个问题。这个问题和“实际代码”都与 alloca() 无关。

标签： c++ optimization gcc compiler-construction llvm

【解决方案1】：

有一个名为 poolalloc 的 LLVM 分支可以进行这种优化。它作为SAFECode 的一部分进行维护，不在主线LLVM 发行版中。

在Chris Lattner 的博士thesis 和this PLDI 论文中对此进行了描述。代码是here。

【讨论】：

【解决方案2】：

从技术上讲，编译器可以优化任何东西，只要它们遵循 As-If 规则。
因此，将堆分配优化为堆栈分配是可能的，但编译器需要足够智能以探测使用情况并确定将分配更改为堆栈不会影响程序的可观察行为。

我不知道有任何编译器会这样做。

【讨论】：