在 Visual C++ 2005 中，编译器可以对 MSIL 代码执行标准本机代码优化很大的子集。从基于数据流的优化到表达式优化，再到循环展开，这一切都包含在内。平台中的其他任何语言都无法做到这一级别的优化。在 Visual C++ .NET 2003 中，全程序优化 (Whole Program Optimization, WPO) 不支持使用 /clr 开关构建，但 Visual C++ 2005 为托管代码添加了这个功能。这个功能启用了跨模块优化，本文后面将会对其进行讨论。

在 Visual C++ 2005 中，托管代码唯一不可用的一种优化是 Profile Guided Optimizations，虽然在以后的版本中可能可用。有关更多信息，请参阅 Write Faster Code with the Modern Language Features of Visual C++ 2005。

JIT 和编译器优化交互

Visual C++ 生成的优化代码提供给 JIT 或 NGEN 以生成本机代码。不管 Visual C++ 编译器生成的代码是 MSIL 还是非托管代码，生成代码的优化器还是十几年前就已开发并已进行调整的优化器。

对 MSIL 代码的优化是对非托管代码进行优化的一个大子集。需要指出的是，允许的优化类随编译器生成的是可验证代码 (/clr:safe) 或非可验证代码 (/clr or /clr:pure) 的不同而不同。在少量的几种情况下，编译器会因为元数据或可验证性限制而无法完成操作，包括缩减运算量（将相乘转换成指针相加），以及将对一个类的私有成员的访问内联到另一个类的方法体中。

Visual C++ 编译器生成 MSIL 代码之后，就可以交给 JIT 进行处理。JIT 读取 MSIL 并开始执行优化，这些优化对 MSIL 中的变化很敏感。一个 MSIL 指令序列也许能够很好地进行优化，但另一个（语义上等同的）序列却可能抑制优化。例如，寄存器分配是一个优化，在这个优化中，JIT 优化器试图将变量映射到寄存器中；寄存器是作为执行算术和逻辑运算的操作数使用的实际硬件。有时，语义上等同但采用两种不同方式编写的代码可能会使优化器在执行良好的寄存器分配上所花费的时间相差巨大。循环展开是一个可能导致 JIT 分配寄存器出现问题的转换的例子。

C++ 编译器完成的循环展开可以公开更多的指令级并行，但也创建了更多活变量 (live variable)，编译器需要使用它们来跟踪寄存器分配。CLR JIT 只能跟踪固定数目的寄存器分配变量；一旦需要跟踪的数目超出这个数目，它就开始将寄存器的内容移到内存中。

因此，必须先后对 Visual C++ 编译器和 JIT 进行微调以生成最佳代码。Visual C++ 编译器负责进行的优化是那些对 JIT 来说太耗时的优化，以及那些在从 C++ 源代码编译为 MSIL 的编译过程中会造成太多信息丢失的优化。

让我们看一下 Visual C++ 对托管代码的一些优化。

公共子表达式消除和代数简化

公共子表达式消除（Common subexpression elimination，CSE）和代数简化 (algebraic simplification) 是两个强大的优化，它们允许编译器在表达式级别执行一些基本优化，以便开发人员可以专注研究算法和体系结构。

下面显示的代码片段分别作为 C# 和 C++ 编译；二者都是在 Release 配置下编译的。变量 a、b 和 c 从一个作为参数传递的数组复制到包含这段代码的函数中：

int d = a + b * c;
int e = (c * b) * 12 + a + (a + b * c);

图 1 显示了 C# 编译器和 C++ 编译器通过这段代码生成的 MSIL，它们都启用了优化。C# 需要 19 条指令，而 C++ 只需 13 条。另外，您可以看到 C++ 代码可以对 b*c 表达式进行 CSE。该编译器可以对 a+a 进行代数简化，即改为生成 2*a，也可以对 (c*b)*12 + c*b 进行代数简化，即改为生成 (c*b)*13。我发现增加的这个 CSE 特别有用，因为我见过编程人员在实际的代码中没有进行这种代数简化。请参阅补充内容“C# 编译器优化”。

全程序优化

Visual C++ .NET 对非托管代码添加了 WPO。而在 Visual C++ 2005 中，这个功能扩展到了托管代码。它不是一次编译和优化一个源文件，而是一次跨所有源文件和头文件进行编译和优化。

现在编译器可以跨多个源文件执行分析和优化。例如，如果没有 WPO，编译器只能在单个编译域中内联函数。有了 WPO，编译器就可以从程序中的所有源文件内联函数。

在以下的示例中，编译器可以做的事情包括跨编译器内联和常量传递，以及其他类型的过程间优化：

// Main.cpp
...
MSDNClass ^MSDNObj = gcnew MSDNClass;
int x = MSDNObj->Square(42);
return x;
...

// MSDNClass.cpp
int MSDNClass::Square(int x)
{
        return x*x;
}

在这个示例中，Main.cpp 调用 Square 方法，而这个方法是另一个源文件中的 MSDNClass 的一部分。当编译时进行 /O2 优化，而不进行全程序优化时，Main.cpp 中产生的 MSIL 如下所示：

ldc.i4.s   42
call       instance int32 MSDNClass::Square(int32)

您可以看到，它首先将值 42 加载到堆栈中，然后调用 Square 函数。作为对照，对于相同的程序，当编译时打开全程序优化时，则生成的 MSIL 如下所示：

ldc.i4     0x6e4

它没有加载 42，也没有调用 Square 函数。相反，在全程序优化下，编译器可以内联来自 MSDNClass.cpp 的函数并进行常量传递。最终的结果只是一条简单的指令 — 加载 42*42 的结果，十六进制表示为 0x6e4。

虽然 Visual C++ 编译器执行的一些分析和优化在理论上 JIT 编译器也可以执行，但对 JIT 编译器的时间限制使得这里提到的许多优化当前还无法实现。一般情况下，NGEN 会比 JIT 编译器更早实现这些类型的优化，因为 NGEN 没有 JIT 编译器必须面对的这类响应时间限制。

[本文共有 3 页，当前是第 1 页] <<上一页 下一页>>