基于熱點函數的代碼體積優化

黃昕

摘 要：為解決嵌入式系統存儲受限的問題，編譯器往往禁止一些會增大代碼體積的優化，如循環展開、過程內聯等，導致性能下降。大部分程序中存在占據程序90%以上執行時間的“熱”代碼，但其體積僅占程序代碼小部分。利用該程序屬性，提出基于熱點代碼的可執行代碼體積優化方法，即通過程序執行剖視信息獲取“熱”、“冷”代碼并采用不同優化方法。測試表明，與針對性能的優化相比，該方法典型測試程序代碼體積平均下降15.2%，性能僅下降3.4%。

關鍵詞：體積優化;編譯;熱點函數;嵌入式應用

DOI：10. 11907/rjdk. 182595

中圖分類號：TP301

文獻標識碼：A文章編號：1672-7800（2019）006-0042-04

Abstract： Due to limit memory capacity of embedded systems， compilers often prohibit some of the optimization that will increase the size of the code， such as loop unroll， procedure inline， etc. This may cause the loss of performance too much. It is observed that in most of programs， the "hot" code consuming 90% or above time of program execution consists of a small part of the whole program. Based on this observation， the paper proposes an executable code optimization methods based on hot code. ?This idea is to use the program execution profile to discover "hot" and "code" codes of a program， and then employ different strategies to optimize these "hot" and "code" codes. The experiment shows that， compared to the existing performance optimization methods， the result by the proposed method can save 15.2% volume of the code with only 3.4% loss of performance on average.

Key Words： code size optimization; compile; hot function; embedded application

0 引言

存儲受限是嵌入式領域面臨的難題，隨著嵌入式系統的發展，越來越復雜的軟件運行在嵌入式系統中，使矛盾日益突出。第一，嵌入式系統本身資源有限，但軟件越來越龐大復雜，要求更大的存儲空間;第二，代碼復雜龐大，使代碼執行開銷日益增加，但用戶對性能的要求也日益提高。因此需要嵌入式軟件既不能占用過多的內存，又要保證提供高效的程序性能。

在嵌入式領域，針對代碼體積優化一般有3種方法[1-2]：

（1）處理器設計上，使用高密度的指令集。例如，Thumb指令集是ARM指令集的子集[3-4]，支持壓縮至16位寬的操作碼，代碼密度更高。ARM程序與Thumb程序可以相互調用，且狀態切換的開銷基本為0。用戶可以根據實際環境切換指令模式生成16位或32位指令，或增加一些復雜指令，實現原來需要兩條指令才能完成的功能。

（2）代碼壓縮技術[5]針對指令編碼進行一系列變化，對可執行代碼進行壓縮，刪除原文件中冗余的信息，減少代碼大小。

（3）編譯優化[6-9]。編譯器在將源程序轉換為可執行程序過程中，以優化代碼體積為目標，執行各種轉換，例如冗余代碼刪除、循環合并等。

與前兩種方法相比，編譯優化技術由于不需要對硬件進行修改，且操作靈活，已在商用與開源編譯器中得到了廣泛應用。例如Intel商用編譯器與開源編譯器GCC、LLVM均提供“Os”選項[6-9]，指明進行針對代碼體積的優化，生成的代碼體積小于缺省的“O2”優化及針對性能的“O3”優化。但現有編譯優化技術在縮小代碼體積的同時，由于對一些會增大代碼體積的優化進行限制，較大程度地影響了性能。

本文首先對在嵌入式領域中應用廣泛的GCC編譯器現有代碼體積優化進行分析、評測，在此基礎上提出基于熱代碼的代碼體積優化技術，通過性能分析工具中找出程序中的“冷”、“熱”代碼，進行分別優化，從而在代碼體積優化的同時盡可能減少對性能的影響，利用Python語言[10]實現自動工具。測試結果證明了該技術的有效性。

1 面向代碼體積的編譯優化

1.1 代碼體積優化技術

無論是Intel商用編譯器，還是開源編譯器GCC、LLVM[6-9]，編譯器針對代碼體積的優化一般包括兩類：

（1）采用刪除冗余代碼、向量化等方法減少代碼體積。冗余代碼刪除指通過刪除程序不必要的計算，減少可執行代碼體積[11]。常用冗余代碼刪除優化方法包括：死代碼刪除、公共表達式刪除、循環不變量外提、常數傳播、復制傳播、代碼提升、值編號、部分冗余刪除等[12-13]。例如在GCC中， GIMPLE語法樹和RTL[14]中間語言均執行了多種冗余刪除優化。向量執行是目前處理器提高性能的主要途徑之一[15]。編譯向量化指利用處理器提供的向量功能部件，包括向量寄存器、向量執行部件，生成可以并發執行的向量指令。一條向量指令同時可以處理多個數據。因此，向量化能夠減少可執行代碼體積。循環合并[16]把多個相鄰且具有相同迭代空間的循環合并成一個循環，一方面增加單個循環體積，為指令調度、冗余刪除等優化提供更多的機會;另一方面，合并循環也刪除了重復的循環判斷、控制變量修改等操作。

以上優化方法通常在減少可執行代碼體積的同時也提升了程序性能。

（2）禁止增大代碼體積的編譯優化。為減少生成的可執行代碼大小，編譯器會禁止一些增大代碼體積的優化。例如，在GCC編譯器[7-8]中，禁止循環展開、基本塊重排與分布、循環分布、插入預取指令等優化。具體指除了禁止循環展開、過程內聯、循環分布等，Os選項會關閉以下優化選項：①align-functions ：函數對齊。align-functions=N 將所有函數起始地址在N（N=1，2，4，8，16…）的邊界上對齊，默認為機器自身默認值，指定為1表示禁止對齊;②align-jumps：跳轉對齊。align-jumps=N 將分支目標在N（N=1，2，4，8，16…）的邊界上對齊，默認為機器自身默認值，指定為1表示禁止對齊;③align-loops ：循環對齊，確保不會在分支目標前插入多余的空指令;④falign-labels ：標號對齊，確保不與falign-jumps產生沖突。對齊優化通常用于提高Cache利用率，為保證對齊，編譯器會進行空指令插入、數據墊塞等，從而增大可執行代碼體積;⑤reorder-blocks/ reorder-blocks-and-partition：基本塊重排和基本塊重排與劃分。通過基本塊重排可提升指令Cache的利用率，但是可能會插入較長的跳轉指令;⑥prefetch- loop-arrays：插入數據預取取指令，以隱藏訪存延遲。

1.2 GCC針對代碼體積的優化評測

對GCC針對可執行代碼體積的優化能力進行測試，測試分為兩個方面：一是使用了Os后代碼體積的減少;二是使用Os對代碼性能的影響。測試在lenoveEdge531機器上進行，測試環境為Linux 內核3.14、gcc 7.2.0編譯器，測試程序選用通用的NPB 3.3-SER[17]基準測試集。

首先對比測試可執行代碼的體積，結果如圖1所示。

顯然，與O3相比，針對代碼體積的Os優化取得了良好效果，可執行代碼體積平均下降了30.5%，尤其是BT、LU和SP，體積下降超過40%。程序EP由于自身代碼量小，去掉注釋僅約230行，因此效果不明顯。代碼體積減少主要得益于Os禁止了會顯著增大代碼體積的優化，但是對性能會產生較大的負面影響，使用Os與O3時性能對比如圖2所示。

與O3相比，采用Os選項，NPB平均執行時間增加了18.3%，尤其是LU與MG程序，執行時間分別上升了59%與43%。

因此目前通過編譯器進行針對代碼體積的優化，最大問題在于對性能的影響，即減小了代碼體積的同時，性能也明顯下降。

2 基于熱點函數的代碼體積優化

2.1 熱點函數

幾乎所有軟件皆存在“熱點”。熱點是指占據程序絕大多數運行時間的代碼。該部分代碼往往僅占程序一小部分。例如，為保證程序正確性、魯棒性，程序中許多代碼用于邊界及錯誤處理，在程序正常運行時通常不被調用或者極少被調用，但代碼量巨大。通過性能分析工具[18-19]，可快速獲得程序熱點函數。以NPB為例，程序熱點函數及熱點函數占據的代碼比例如表1所示，多數程序占據程序執行時間90%以上的熱點函數，代碼量僅為總代碼量的30%。

2.2 可執行代碼體積優化

利用程序“熱點”函數屬性，可通過對“熱”、“冷”代碼區別對待，在降低對程序性能影響前提下，盡可能優化可執行代碼體積，即針對占據程序大部分執行時間的“熱點”函數，進行代碼性能優化;針對占據程序大部分代碼體積的“冷”代碼，進行代碼體積優化。算法流程如圖3所示。

優化主要分為3步：①獲取熱點函數;②設置熱點函數標記位，在編譯該函數時，采用性能優先的優化方法;③使用帶按摩大小有限的編譯選項Os，生成編譯命令。利用代碼運行時獲取的性能信息（運行剖視profile文件）[18-19]，可較為精確地獲取程序熱點代碼。在沒有運行剖視文件的情況下，利用編譯基于啟發信息的靜態分析，也可大致獲取熱點函數。編譯器編譯時通常以函數為單位，設置熱點函數標記位，編譯到該函數時，修改選項為性能優先。其它函數均使用代碼大小優先的選項進行編譯，保證頻繁執行的熱點函數執行時間不發生大幅下降。其它程序部分進行針對代碼大小的優化，減少可執行代碼體積。

3 測試

測試在lenoveEdge531機器上進行。對于熱點函數采用O3優化，其它函數采用Os優化。優化后的結果對比如表2-表8所示。

從測試結果可以看出，基于熱點函數的可執行代碼體積優化取得了較理想結果：①和O3相比，性能最多僅下降15.5%（LU），平均下降3.4%，但是代碼積平均下降15.2%;②和Os相比，代碼體積平均僅增加8.3%，但是性能提高了7.5%。

4 結語

存儲受限是嵌入領域面臨的主要問題之一。目前針對代碼體積的編譯優化對性能有較大影響，本文提出基于熱點代碼的可執行代碼體積優化，在盡可能不影響性能的前提下，減少程序可執行代碼體積。利用NPB測試程序驗證了方法及工具的效果，下一步研究將使用典型嵌入式程序，例如Arduino智能小車[20]，對方法進行驗證;同時將自動工具與程序Makefile等結合，進一步實現優化過程的完全自動化。

參考文獻：

[1] BESAEDES A，FERENC R，GYIMóTHY T，et al. Survey of code-size reduction methods[J]. ACM Computing Surveys，2003，35（3）：223-267.

[2] 廉玉龍.面向嵌入式處理器的編譯優化技術研究[D]. ?杭州：浙江大學， 2016.

[3] ARM Ltd. Thumb？ 16-bit Instruction Set[R/OL] ?http：//infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf.Accessed：2018-10-02.

[4] ARM Ltd. ARMv7-M Architecture Reference Manual[R/OL]. https：//static.docs.arm.com/ddi0403/e/DDI0403E_B_armv7m_arm.pdf.

[5] SUTTER B and BOSSCHERE K. Software techniques for program compaction[J]. ?Communications of the ACM， 2003， 46（8）：33-34.

[6] INTEL Corp. Intel？ Parallel Studio XE 2018[R/OL]. https：//software.intel.com/en-us/parallel-studio-xe， 2018.

[7] BESZéDES A，GERGELY T，GYIMOTHY T，et al. Optimizing for space ： measurements and possibilities for improvement[C]. ?Proceedings of the 2003 GCC Developers' Summit， 2003：7-20.

[8] ANORMITY. Using the GNU compiler collection（GCC）[EB/OL]. ?http：//gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc.

[9] ANORMITY. LLVM user guides[EB/OL]. http：// https：//llvm.org/docs/GettingStarted.html.2018.

[10] BEAZLEY D & JONES B K. Python cookbook. [M]. ?3rd Edition. Sebastopol ：ORelly Media. Inc，2013.

[11] STEVEN M. Advanced compiler design and implementation[M]. ?San Francisco：？ Morgan Kaufmann， 1997.

[12] BRIGGS P， COOPER K D， SIMPSON L T. Value numbering[J]. ?Software-Practice and Experience， 1997，17（6）：701-724.

[13] XUE J ，CAI Q. A life optimal algorithm for speculative PRE[J]. ?ACM Transactions on Architecture and Code Optimizaion， 2006， 3（3）： 115-155.

[14] ANORMITY. GNU compiler collection （GCC） internals. [EB/OL]， https：//gcc.gnu.org/onlinedocs/gccint/index.html. 2018

[15] 高偉，趙榮彩，韓林，等. ?SIMD自動向量化編譯優化概述[J]. ?軟件學報，2015，25（6）：1265-1284.

[16] KENNEDY K， RANDY A. Optimizing compilers for modern architectures： a dependence-based approach[M]. San Francisco：Morgan Kaufmann. 2001.

[17] NASA. NPS ?parallel benchmarks[R/OL]. http：//nas.nasa.gov/Software/NPB.

[18] GNU Gprof. [EB/OL]. http：//sourceware.org/binutils/docs/gprof/index.html. 2018.

[19] INTEL Corp. Intel Vtune Amplifier[R/OL]. ?https：//software.intel.com/en-us/intel-vtune-amplifier-xe/.

[20] ANOMITY. Adruino smart car[EB/OL]. ?https：//create.arduino.cc.

（責任編輯：江 艷）