
平臺(tái) 論壇博客文庫

論壇徽章:: 0

電梯直達(dá)

1樓 [收藏(0)] [報(bào)告]

發(fā)表于 2007-05-27 23:04 |只看該作者 |倒序?yàn)g覽

本文側(cè)重介紹了 GCC 4.0 內(nèi)部結(jié)構(gòu)相對(duì)于 3.4.x 版本的一些全新變化。
GCC(GNUCompiler Collection) 是 GNU(GNU's Not Unix) 計(jì)劃提供的編譯器家族，它能夠支持C, C++,Objective-C, Fortran, Java 和 Ada 等等程序設(shè)計(jì)語言前端，同時(shí)能夠運(yùn)行在 x86,x86-64, IA-64,PowerPC, SPARC 和 Alpha 等等幾乎目前所有的硬件平臺(tái)上。鑒于這些特征，以及 GCC編譯代碼的高效性，使得GCC成為絕大多數(shù)自由軟件開發(fā)編譯的首選工具。雖然對(duì)于程序員們來說，編譯器只是一個(gè)工具，除了開發(fā)和維護(hù)人員，很少有人關(guān)注編譯器的發(fā)展，但是GCC的影響力是如此之大，它的性能提升甚至有望改善所有的自由軟件的運(yùn)行效率，同時(shí)它的內(nèi)部結(jié)構(gòu)的變化也體現(xiàn)出現(xiàn)代編譯器發(fā)展的新特征，所以2005年4月20日，GNU 組織發(fā)布的 GCC 4.0 引起了廣泛的關(guān)注。那么這次 GCC 從 3.4.x 直接躍遷到4.x的主版本變化到底有什么值得關(guān)注的呢？
我們可以從不同的角度看待 GCC 的這次變遷，對(duì)于普通程序員來說，關(guān)注的主要是GCC 的前端支持情況以及編譯性能的變化。
1. GCC 4.0 的前端支持
GCC的開發(fā)者和使用者當(dāng)中，大多數(shù)人都是 C 或者 C++ 的用戶，所以 GCC 對(duì)Fortran語言支持不足也不令人奇怪。但是，這并不代表Fortran 是無足輕重的，事實(shí)上，開發(fā)商業(yè)的 Fortran 編譯器的公司要遠(yuǎn)遠(yuǎn)多于開發(fā) C 和C++ 編譯器的公司。
在科學(xué)計(jì)算和工程應(yīng)用領(lǐng)域，程序員們?nèi)匀辉陬l繁使用Fortran程序，同時(shí)，大量的經(jīng)過長(zhǎng)時(shí)間考驗(yàn)的函數(shù)庫也為Fortran語言的數(shù)值計(jì)算提供了強(qiáng)有力的支持，所以，在一些"超級(jí)計(jì)算機(jī)"(supercomputer)上，F(xiàn)ortran仍然是絕大多數(shù)應(yīng)用的首選語言。
然而，在GCC4.0發(fā)布之前，如果不想購(gòu)買商用的Fortran編譯器，那么程序員們的唯一選擇就是GNU的g77編譯器。但是g77編譯器是一個(gè)相當(dāng)陳舊的技術(shù)，很多Fortran語言的新特性都不能支持，比如流行的Fortran95，它能夠支持的模塊化編程，并行處理和數(shù)組操作等等，g77編譯器基本上都無法支持。
這次GCC4.0發(fā)布時(shí)推出了支持Fortran95語言前端的編譯器gfortran，它已經(jīng)能夠大大超越g77編譯器，支持Fortran95標(biāo)準(zhǔn)中的很多新特性，雖然gfortran還有一些缺陷，比如不能支持自動(dòng)并行化(automaticparallelization)，不能支持Fortran2003中的面向?qū)ο筇匦缘鹊�，它已�?jīng)給了Fortran程序員除了商業(yè)編譯器和g77以外一個(gè)更好的選擇。
2. GCC 4.0的編譯性能
編譯器的性能主要可以從三個(gè)方面來考查：
1. 編譯時(shí)間(compile time)，指編譯器編譯一個(gè)源程序得到目標(biāo)代碼所需要的時(shí)間。
2. 目標(biāo)代碼的大小(object size)，編譯得到的目標(biāo)代碼當(dāng)然是越精悍越好了。
3. 目標(biāo)代碼運(yùn)行時(shí)間(run time)，運(yùn)行時(shí)間體現(xiàn)了速度和效率。
這里，作者沒有親自測(cè)試和實(shí)驗(yàn)，引用了Scott Robert Ladd的《GCC 4.0: A Review for AMDandIntelProcessors》文章中的一些實(shí)驗(yàn)結(jié)果。這篇文章引起了比較大的反響，其實(shí)驗(yàn)結(jié)果和結(jié)論也得到了廣泛的認(rèn)可，如果對(duì)Scott的具體測(cè)試采用的軟硬件平臺(tái)和工具方法感興趣，原文可以在http://www.coyotegulch.com/reviews/gcc4/index.html看到。
Scott 使用AMD和Intel的兩款處理器：64位的Opteron處理器和32位的Pentium4處理器，分別針對(duì)GCC3.4.3和GCC 4.0來進(jìn)行測(cè)試。他選用了POV-Ray 3.6.1, LAME 3.96.1, SciMark2.0和Linux2.6.11.8作為benchmark來進(jìn)行測(cè)試，分別記錄了GCC 3.4.3和GCC 4.0在ADMOpteron和IntelPentium 4下的編譯時(shí)間、代碼大小和代碼運(yùn)行時(shí)間進(jìn)行比較，具體的實(shí)驗(yàn)結(jié)果請(qǐng)參見原文。
這樣，根據(jù)這些實(shí)驗(yàn)數(shù)據(jù)，我們可以給出一個(gè)粗糙的結(jié)論，在編譯性能方面，GCC 4.0似乎不如GCC3.4.3，因?yàn)樵诤芏鄷r(shí)候，GCC4.0的編譯時(shí)間、代碼大小以及代碼運(yùn)行時(shí)間全面高于GCC3.4.3。這樣的結(jié)果看似出人意料，GCC這次大的版本變化就是因?yàn)橐肓诵碌膬?yōu)化框架，怎么會(huì)編譯性能有所下降呢？這主要是因?yàn)椋菏紫�，這是一次主版本變化，我們可以理解巨大的變化帶來的性能損耗；另外，更主要的是，GCC新的優(yōu)化框架的潛力尚未完全發(fā)揮出來，這一點(diǎn)，在我們文章結(jié)束的時(shí)候，讀者會(huì)有更深的理解。
3. GCC 4.0 的內(nèi)部結(jié)構(gòu)變化
GCC 遵循 GPL 協(xié)議，是開放源代碼的，其開發(fā)過程也是完全開放的，任何人都可以對(duì) GCC 的發(fā)展作出貢獻(xiàn)，因而 GCC 特別適合用于學(xué)習(xí)和研究編譯器。對(duì)于學(xué)習(xí)和研究編譯器本身來說，GCC 內(nèi)部的結(jié)構(gòu)變化顯然更吸引人。
目前 GCC 發(fā)行維護(hù)者 Mark Mitchell 在接受 internetnews.com 網(wǎng)站采訪時(shí)這樣說到："毫無疑問地，GCC4.0中最引人注意的特性以及為何把 GCC 的這個(gè)版本稱作 4.0 而不是3.5，就是因?yàn)槠湫碌膬?yōu)化框架(optimizationinfrastructure)。大體上來說，GCC以前的版本的代碼優(yōu)化工作主要在底層機(jī)器指令級(jí)別進(jìn)行的。不幸的是，到了底層的時(shí)候，很多信息已經(jīng)丟失了，因此，GCC 4.0在更接近輸入高級(jí)語言程序的級(jí)別上做了很多優(yōu)化工作。"
Mark Mitchell 所說的 GCC 新的優(yōu)化框架主要就是指 Tree SSA(StaticSingleAssignment)，Tree SSA 經(jīng)過長(zhǎng)時(shí)間的獨(dú)立開發(fā)，最終整合進(jìn)了GCC的主流(mainstream)中，可見這種設(shè)計(jì)是意義非凡的。Tree SSA 是什么？為什么要采用 Tree SSA? 使用了TreeSSA 的 GCC 有什么不同？新的 GCC 編譯和優(yōu)化框架是什么樣的？等等，這些將是本文探討的主要問題。
這部分文章內(nèi)容是這樣組織的：首先回顧 GCC 4.0 版本之前的編譯流程，以便進(jìn)行對(duì)比；接下來介紹 GCC4.0的編譯流程以及新的優(yōu)化框架結(jié)構(gòu)，這里先介紹 GENERIC Tree和 GIMPLETree，SSA形式等基本概念，在讀者對(duì)這些概念和理論有了一定的了解之后，再介紹 GCC 中是如何實(shí)現(xiàn) Tree SSA 框架結(jié)構(gòu)的。
3.1 GCC 4.0 之前的編譯流程
這里有必要回顧一下 GCC4.0之前的版本進(jìn)行代碼優(yōu)化的框架結(jié)構(gòu)，以便進(jìn)行對(duì)比分析。GCC的前端在接受了輸入的源程序之后，經(jīng)過分析器(parser)處理得到 ParseTree（通常是一種抽象語法數(shù)，AST, AbstractSyntax Tree），根據(jù)這個(gè) Parse Tree生成程序的RTL(Register Transfer Language)表示，然后在RTL表示的基礎(chǔ)上進(jìn)行優(yōu)化處理，然后生成相應(yīng)的目標(biāo)代碼，如下圖 1 所示。
但是 RTL 表示是一個(gè)相當(dāng)接近底層的表示，也就是說它更接近目標(biāo)代碼，適合進(jìn)行目標(biāo)相關(guān)的優(yōu)化工作，比如寄存器分配等等。然而，很多的優(yōu)化轉(zhuǎn)換工作需要更高層的程序信息，比如數(shù)組引用、數(shù)據(jù)類型、控制流結(jié)構(gòu)等等，這些很難用 RTL 表示，或者無法用 RTL表示。
圖1. GCC 4.0之前版本的代碼編譯流程和優(yōu)化框架

3.2 GCC 4.0 的優(yōu)化框架(Optimization Infrastructure)
提供一個(gè)可移植性強(qiáng)、跨平臺(tái)以及編譯高效代碼的編譯器，是 GCC 一貫追求的目標(biāo)，為了使GCC能夠獲得更好的編譯性能，高層程序信息級(jí)別的優(yōu)化工作是必須的。TreeSSA設(shè)計(jì)的主要目的就在于此，它既與前端語言無關(guān)，又與后端目標(biāo)無關(guān)，而且能夠提供在 RTL表示層很難或者無法進(jìn)行的高級(jí)分析和轉(zhuǎn)換。
Tree SSA 起先是作為 GCC 的一個(gè)分支(branch)進(jìn)行獨(dú)立開發(fā)的，經(jīng)過兩年多的努力開發(fā)，終于在 2004 年 5 月13日進(jìn)入了 GCC 的主流版本。在 GCC 的 SSA for Trees 分支的網(wǎng)頁上明確說明了，這個(gè)項(xiàng)目的目的就是構(gòu)建一個(gè)對(duì)基于SSA形式的樹的優(yōu)化框架。在學(xué)習(xí)編譯原理的時(shí)候我們知道，編譯器通常會(huì)使用樹的形式來描述程序，GCC也是這樣，在接受了輸入的源程序后，GCC驅(qū)動(dòng)其相應(yīng)語言的前端分析器(parser)，處理得到一個(gè) Tree。從圖 1 可以看到，4.0版本之前的 GCC 幾乎是立即把這些 Tree轉(zhuǎn)換成了 RTL 表示。那么現(xiàn)在 GCC4.0 的 Tree SSA 優(yōu)化框架就是在前端生成Parse Tree 之后，把這些 Tree轉(zhuǎn)換成基于 SSA 的 Tree，對(duì)這些 SSA 形式的 Tree 進(jìn)行高層次的優(yōu)化，然后才把Tree 轉(zhuǎn)換成 RTL 表示。
3.2.1 GENERIC Tree 和 GIMPLE Tree
這個(gè)框架結(jié)構(gòu)看起來比較簡(jiǎn)單，而且 GCC 的 Parse Tree 能夠提供足夠的信息來實(shí)現(xiàn)SSA，但是在真是實(shí)施的時(shí)候，還是有很大的困難的，最主要的兩個(gè)困難是這樣的：
1. GCC 中的樹沒有統(tǒng)一的表示形式，每一個(gè)前端都定義了自己的樹。這就意味著要得到基于 SSA 形式的樹必須要對(duì)每種前端分析生成的樹都進(jìn)行處理。
2. GCC 前端得到的 Parse Tree 的復(fù)雜度是無法估量的。把這些樹轉(zhuǎn)換成基于 SSA形式的樹需要進(jìn)行復(fù)雜的處理工作。
為了解決以上兩個(gè)問題，GCC Tree SSA 分支的開發(fā)小組引入了 GENERIC Tree 和GIMPLE Tree 兩個(gè)概念：
1. GENERIC Tree 是特意創(chuàng)造出來的 GCC 通用的樹的表示形式，它能夠表示不同的前端所需要的所有的結(jié)構(gòu)，而且又能夠去除語言相關(guān)性。
2. GIMPLE Tree是取自GENERIC Tree和SIMPLE兩個(gè)短語的。因?yàn)镚ENERIC Tree的復(fù)雜性導(dǎo)致實(shí)現(xiàn)SSA形式的困難，需要把GENERIC Tree進(jìn)行簡(jiǎn)化，這種簡(jiǎn)化的GENERIC Tree就稱之為GIMPLE Tree。
好了，了解了這些內(nèi)容之后，我們可以看看 GCC 4.0 的編譯流程和優(yōu)化框架，如下圖2所示：
圖2. GCC 4.0 的編譯流程和優(yōu)化框架

3.2.2 Single Static Assignment Form 的基礎(chǔ)介紹
到現(xiàn)在為止，我們基本搞清了新的 GCC 的編譯過程，也大概了解了所謂的新的 Tree SSA 優(yōu)化框架。上面提到的 GENERICTree 和GIMPLE Tree 都是為了實(shí)現(xiàn) SSA 而做的準(zhǔn)備工作，那么 SSA 本身究竟是什么？為什么 GCC 要把 ParseTree轉(zhuǎn)換成基于 SSA 形式的 Tree 再做優(yōu)化工作呢？為弄清楚這些問題，我們有必要多花一些篇幅對(duì)SSA的基本概念和理論做一些介紹。
SSA 的全稱是 Static Single Assignment，直譯過來就是靜態(tài)單一賦值，它是IBM公司在上個(gè)世紀(jì)80年代研究的成果。從前面的討論可以看出，Tree SSA 與 RTL 一樣，也是一種中間表示形式，不過相比 RTL要更高層一點(diǎn)。SSA形式是一種相對(duì)而言比較新穎的中間表示形式，早期的講編譯原理或者編譯器的課本中大多沒有提及。
簡(jiǎn)單的說，SSA 形式就是每個(gè)變量只能被賦值一次。這樣，非 SSA 形式的程序在轉(zhuǎn)換成 SSA 形式的時(shí)候，其中的部分變量就會(huì)被分割成很多版本，通常使用下標(biāo)來表示這些不同的版本。下面舉一個(gè)簡(jiǎn)單的例子來說明，如下圖 3 所示：
圖3. 程序的非 SSA 形式和 SSA 形式

上圖中所示的代碼片段，由于 y 變量被賦值兩次，所以在轉(zhuǎn)化成 SSA 形式的時(shí)候，y變量被分割成兩個(gè)版本 y1 和 y2，這樣就保證了每個(gè)變量?jī)H僅被賦值一次。
由于 SSA 形式中每個(gè)變量只能被賦值一次，那么SSA形式就能有效地把程序中所操作的數(shù)值和這些數(shù)值的存儲(chǔ)位置這兩者分開，這樣就能方便一些優(yōu)化工作。比如我們剛才看的圖3中的代碼片段，我們可以通過肉眼分析發(fā)現(xiàn)在非 SSA 形式中的第一條語句y := 1是一條無效的冗余語句，真正決定 y 變量值的是第二條y:=2賦值語句。那么在代碼優(yōu)化的時(shí)候，第一條語句就應(yīng)該被刪除掉。但是這是我們?nèi)斯ぐl(fā)現(xiàn)的優(yōu)化結(jié)果，如果想要編譯器來完成這個(gè)優(yōu)化工作，需要進(jìn)行復(fù)雜的分析，在編譯原理中稱之為"定義可達(dá)性分析"(reaching definition analysis)。而在SSA形式中，顯然，做出這樣的優(yōu)化決定則無需進(jìn)行太多分析。
這只是 SSA 形式諸多優(yōu)點(diǎn)中的一個(gè)而已，使用 SSA 形式可以利用更多的編譯器優(yōu)化算法或者是提高這些算法的效率，比如constantpropagation, sparse conditional constant propagation, deadcodeelimination, global value numbering, partial redundancyelimination以及register allocation 等等。這里涉及太多編譯理論和算法，本文不作詳細(xì)討論。
SSA 形式具有上文所述的優(yōu)點(diǎn)，當(dāng)然也會(huì)有其復(fù)雜和困難的地方了，下面我們通過一個(gè)稍微復(fù)雜點(diǎn)的程序片段來說明把非 SSA 形式的程序轉(zhuǎn)換成 SSA 形式程序的時(shí)候有些什么需要考慮的問題：

圖 4-a 所示的非 SSA 形式的程序在轉(zhuǎn)換成了圖 4-b 所示的 SSA 形式的程序后，有一個(gè)問題很難解決，就是圖 4-b中最下面程序塊中y 的值無法確定。因?yàn)樵诖酥坝幸粭l選擇語句，導(dǎo)致程序控制流產(chǎn)生了分支，此時(shí) y 的值可能是 y1也可能是y2，這是由程序具體執(zhí)行時(shí)經(jīng)過哪一條控制流來決定的。處理的方法是在最后一塊程序片段之前加上一個(gè) Φ 函數(shù)，定義一個(gè)新的 y3，并從y1 或者y2 中選擇一個(gè)適當(dāng)?shù)闹蒂x給 y3，如圖 4-c 所示。
推而廣之，在將非 SSA 形式的程序轉(zhuǎn)換成 SSA 形式后，如果某個(gè)變量被分割成了n個(gè)不同版本的變量后，在某一點(diǎn)需要會(huì)合，那么在這個(gè)會(huì)合點(diǎn)(joint point) 就需要加入一個(gè) Φ 函數(shù)來確定應(yīng)該選擇這 n個(gè)不同版本的變量中的某一個(gè)值。這樣問題就轉(zhuǎn)變成了如何計(jì)算這個(gè) Φ函數(shù)以及確定在程序中的什么位置應(yīng)該插入 Φ 函數(shù)，這個(gè)可以使用dominance frontiers 來進(jìn)行計(jì)算，關(guān)于如何高效計(jì)算這個(gè) Φ函數(shù)的算法研究本文不作深入討論。
3.2.3 GCC 4.0 中的 Tree SSA 框架的設(shè)計(jì)和實(shí)現(xiàn)
至此，我們已經(jīng)比較清楚的了解了什么是 SSA，SSA形式有什么好處，如何將非SSA表示轉(zhuǎn)換成基于SSA形式的表示以及這個(gè)過程中需要解決的主要問題等等，本文將不再對(duì)SSA進(jìn)行深入的討論了，回到我們的主題，繼續(xù)討論GCC4.0 的 Tree SSA 優(yōu)化框架是如何設(shè)計(jì)和實(shí)現(xiàn)的，它是怎樣把 Tree SSA 融入到 GCC 的編譯過程中去的。
回顧上圖 2表示的 GCC 4.0 編譯流程，在得到 GIMPLE Tree 之后，經(jīng)過 GIMPLE optimizer 和GIMPLEexpander 的處理，得到了程序的 RTL 表示。其實(shí)把程序轉(zhuǎn)換成SSA形式和在此基礎(chǔ)上進(jìn)行優(yōu)化就在這個(gè)過程中完成的，下面我們就來具體看看GCC 4.0 是怎么做的。在 GIMPLE 和 RTL之間是樹優(yōu)化 (Tree Optimization) 的過程，如下圖 5 所示。圖 5中所示的樹優(yōu)化器 (Tree Optimizer)主要完成這幾個(gè)功能：
1. 生成一個(gè)控制流轉(zhuǎn)換圖 CFG(Control Flow Graph)。
2. 將 GIMPLE Tree 轉(zhuǎn)換成基于 SSA 形式的 Tree。
3. 進(jìn)行 Tree SSA 的優(yōu)化。
4. 將優(yōu)化后的基于 SSA 形式的 Tree 轉(zhuǎn)換成 RTL 接口所能識(shí)別的非 SSA Tree 的形式。
圖5. GCC 4.0 的 Tree Optimizer 結(jié)構(gòu)

結(jié)合 GCC 4.0 代碼中的部分源文件來說明：圖 5 中這個(gè) Tree Optimizer的行為是由tree-optimize.c文件驅(qū)動(dòng)的，tree-ssa.c, tree-into-ssa.c 以及tree-outof-ssa.c 負(fù)責(zé)完成 SSA形式的轉(zhuǎn)換、驗(yàn)證以及其他需要與 SSA 形式交互的功能，建立和管理控制流轉(zhuǎn)換圖 CFG的工作由 tree-cfg.c完成。不同的樹分析和優(yōu)化功能分別在相應(yīng)的源文件中獨(dú)立實(shí)現(xiàn)，這些分析和優(yōu)化函數(shù)必須向 GCC 注冊(cè)，然后才能由tree-optimize.c進(jìn)行驅(qū)動(dòng)和管理，結(jié)合圖 5來看，SSA pass1, SSA pass2 … SSA passn代表了實(shí)現(xiàn)各種不同功能的 SSA分析器，他們向 Tree Optimizer 注冊(cè)，在編譯時(shí)刻 TreeOptimizer根據(jù)編譯選項(xiàng)等等選擇相應(yīng)的SSA分析器進(jìn)行優(yōu)化或者其他處理工作，并保證在基于 SSA 形式的處理完成之后將 SSA樹轉(zhuǎn)換成非SSA樹，交給下面的 RTL 模塊處理。
至此，GCC 4.0 的 Tree SSA優(yōu)化框架結(jié)構(gòu)應(yīng)該比較清楚了。讀者可能會(huì)注意到，文中多次提到TreeSSA是一個(gè)優(yōu)化框架結(jié)構(gòu)(OptimizationInfrastructure)，為什么說是一個(gè)Infrastructure 呢？其實(shí)把Infrastructure稱作框架結(jié)構(gòu)或許并不貼切，更精確地說 Tree SSA是 GCC 提供的一種進(jìn)行優(yōu)化工作的基礎(chǔ)設(shè)施。圖 5中已經(jīng)體現(xiàn)出了這一點(diǎn)，TreeSSA的分析和優(yōu)化工作不是一成不變的，具體選擇哪些優(yōu)化功能和算法是由TreeOptimizer選擇驅(qū)動(dòng)的，而且這個(gè)Infrastructure是相當(dāng)靈活的，我們可以很方便的加入一個(gè) SSA 分析器，只需要如下步驟：
1. 創(chuàng)建一個(gè) struct tree_opt_pass 類型的全局變量。
2. 在 tree-pass.h 頭文件中為這個(gè)新的分析器添加一個(gè)外部聲明(extern declaration)。
3. 調(diào)用 NEXT_PASS 把這個(gè)新的分析器加入到 tree-optimize.c: init_tree_optimization_passes 序列中。
所以這種 Infrastructure 是一個(gè)相當(dāng)靈活和方便的設(shè)計(jì)，使得我們可以便利地加入新的SSA 分析器，或者使用更高效的算法來重新設(shè)計(jì)完成一些優(yōu)化功能等等。
4. 總結(jié)
GCC 4.0發(fā)布以來得到了引起了廣泛的關(guān)注，新的 gfortran 前端給Fortran程序員帶來了福音，但也有很多不盡如人意的地方，比如編譯性能的損耗，以及向后兼容問題。比如KDE(K DesktopEnvironment)開發(fā)小組在發(fā)現(xiàn) GCC 4.0 無法正常編譯 KDE 后，迅速的拋棄了 GCC 4.0。而且，出于穩(wěn)定性的考慮，GCC3.x版本的開發(fā)仍然在進(jìn)行中。這些似乎給 GCC 4.0 的前景籠罩上了一層陰影，但我們應(yīng)該容忍一點(diǎn)，給 GCC4.0一些信心，向后兼容的問題應(yīng)該是能夠解決的。
至于編譯性能的問題，通過我們這篇文章的討論，我們可以看到 GCC 4.0 Tree SSA 的優(yōu)化框架結(jié)構(gòu)并沒有充分發(fā)揮出其潛能，還可以增加和改進(jìn)更多 Tree SSA 的優(yōu)化工作，假以時(shí)日，GCC 4.0 的編譯性能會(huì)得到提高的。
總的來說，這次 GCC 從 3.x 版本躍遷到 4.x 版本更像一個(gè)進(jìn)化 (evolution)的過程，而非一個(gè)革命性(revolution) 的過程，它采用的 Tree SSA 優(yōu)化框架代表了編譯器發(fā)展的方向，我們應(yīng)該關(guān)注 GCC4.0 的進(jìn)一步發(fā)展。

[ 本帖最后由 OpenPro 于 2007-5-28 19:18 編輯 ]