0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

編譯器理論之別名分析分類

openEuler ? 來源:openEuler ? 作者:openEuler ? 2022-09-14 10:51 ? 次閱讀

1.簡介

別名分析是編譯器理論中的一種技術,用于確定存儲位置是否可以以多種方式訪問。如果兩個指針指向相同的位置,則稱這兩個指針為別名。但是,它不能與指針分析混淆,指針分析解決的問題是一個指針可能指向哪些對象或者指向哪些地址,而別名分析解決的是兩個指針指向的是否是同一個對象。指針分析和別名分析通常通過靜態(tài)代碼分析來實現。

別名分析在編譯器理論中非常重要,在代碼優(yōu)化和安全方面有著非常廣泛且重要的應用。編譯器級優(yōu)化需要指針別名信息來執(zhí)行死代碼消除(刪除不影響程序結果的代碼)、冗余加載/存儲指令消除、指令調度(重排列指令)等。編譯器級別的程序安全使用別名分析來檢測內存泄漏和內存相關的安全漏洞。

2.別名分析分類

別名分析種類繁多,通常按如下屬性進行分類:域敏感度(field-sensitivity)、過程內分析(Intra-Procedural)v.s.過程間分析(Inter-Procedural)、上下文敏感度(context-sensitivity)和流敏感度(flow-sensitivity)。

2.1 域敏感(Field-Sensitivity)

域敏感度是對用戶自定義類型進行分析的一種策略(亦可以處理數組)。在域敏感維度共有三種分析策略:域敏感(field-sensitive)、域非敏感(field-insensitive)、域基礎分析(field-based)。以下面代碼為例:

structTest{
intfield1;
intfield2;
}

Testa1;
Testa2;

Note:field這里為結構體或者類的數據成員。

域非敏感:對每個對象建模,而對對象中的成員不進行處理;其建模后的結果如下圖,僅有a1.*和a2.*的區(qū)別:

40092054-334d-11ed-ba43-dac502259ad0.png

域基礎分析:僅對結構體中的成員進行建模,而不感知對象。其建模后的結果如下圖,僅有*.field1和*.field2:

40233764-334d-11ed-ba43-dac502259ad0.png

域敏感:既對對象建模,又對成員變量進行處理。其建模后的結果如下圖,有a1.field1、a1.field2、a2.field1、a2.field2:

403a31b2-334d-11ed-ba43-dac502259ad0.png

處理數組時,相同的原則亦適用。以C整數數組為例:int a[10],域非敏感分析僅使用一個節(jié)點建模:a[*],而域敏感分析創(chuàng)建10個節(jié)點:a[0]、a[1]、...、a[9]。

總結:域敏感別名分析準確性高,但是當存在嵌套結構或者大數組時,節(jié)點數量會迅速增加,分析成本也會陡然上升。

2.2 過程內分析(Intra-Procedural)v.s.過程間分析(Inter-Procedural)

過程內分析僅分析函數體內部的指針,并沒有考慮與其他函數之間的相互影響。需要特別指出的是,過程內分析當處理包含指針入參的函數或者返回指針的函數時,其分析可能不夠準確。相反,過程間分析會在函數調用過程中處理指針的行為。

過程內分析不易于擴展,精度較低。相比過程間分析,過程內分析更容易實現,且過程內/間分析與上下文敏感度分析高度相關,因為一個上下文敏感分析必定是一個過程間分析。

2.3 上下文敏感度(Context-Sensitivity)

上下文敏感度用來控制函數調用該如何分析。有兩種分析方法:上下文敏感(context-sensitive) 和上下文非敏感(context-insensitive)。上下文敏感在分析函數調用的目標(被調用者)時考慮調用上下文(調用者)。以如下代碼為參考[1]:

1publicstaticvoidmain(String[]args){
2Stringname1=getName(3);//Tainted
3Stringsql1="select*fromuserwherename="+name1;
4sqlExecute(sql1);//TaintSink
5
6Stringname2=getName(-1);//NotTainted
7Stringsql2="select*fromuserwherename="+name2;
8sqlExecute(sql2);
9}
10
11privatestaticStringgetName(intx){
12if(x>0){
13returnSystem.getProperty("name");
14}else{
15return"zhangsan";
16}
17}

如上所示,getName()方法基于入參的不同,會返回不同的結果,在第2行和第6行,獲取到的name1和name2的污點信息不同,當入參為3時,返回的是一個從環(huán)境變量中獲取的污染的數據,導致sql注入,而當入參為-1時,返回的是一個常量,不是污染數據,不會有問題。在上下文敏感的分析中,在第4行應該報一個sql注入問題,而在第8行則不應該報sql注入問題。而上下文非敏感的分析中,不考慮傳入參數的不同,getName()方法則全部返回一個{System.getProperty("name")}∨{zhangsan},從而導致第4行和第8行都會報一個sql注入的問題。

上下文敏感別名分析需要有一種方法,為函數getName創(chuàng)建抽象描述,以便每次調用它時,分析器都可以將調用上下文應用于抽象描述。

總結:上下文敏感分析比較準確,但是增加了復雜度。

2.4 流敏感度(Flow-Sensitivity)

流敏感度是一種是否考慮代碼順序的原則。有兩種方法:流敏感(flow-sensitive)和流非敏感(flow-insensitive)。

流非敏感不考慮代碼順序,并為整個程序生成一組別名分析結果,而流敏感考慮代碼順序,計算程序中每個指針出現的位置的別名信息。以如下代碼為例:

1inta,b;
2int*p;
3p=&a;
4p=&b;

流非敏感的分析結果是針對整個代碼塊,其結果應該是:指針p可能指向變量a或者變量b。流敏感生成的別名信息是,在第3行,指針p指向變量a,在第4行以后指針p指向變量b。

Note:當程序具有許多條件語句、循環(huán)或遞歸函數時,流敏感分析的復雜性會大大增加。要執(zhí)行流敏感分析,需要完整的控制流圖。因此,流敏感分析非常精確,但對于大多數情況來說,它的分析成本過高,無法在整個程序上執(zhí)行。

3.別名分析常見算法介紹

常見的別名算法共有三種:Andersen's指針分析算法、Steensgaard's指針分析算法和數據結構分析算法。

Andersen's指針分析是一種流非敏感和上下文非敏感的分析算法。Andersen's指針分析算法復雜度較高,實踐應用性較差,其時間復雜度為,其中n為指針節(jié)點個數。

Steensgaard's指針分析算法也是一種流非敏感,上下文非敏感且域非敏感的別名分析算法。其時間復雜度較低,實現相對簡單,實踐應用廣,其時間復雜度為,其中無限接近于1,但是其別名分析的準確性較低。

數據結構分析算法是一種流非敏感,上下文敏感和域敏感的算法。其時間復雜度較低,為O(n * log(n)) ,應用性較好,但是由于不支持MustAlias(參考“AliasAnalysis Class概覽”章節(jié)),導致其應用有局限性。

4.別名分析在LLVM中的應用與實現

4.1 應用

別名分析在代碼優(yōu)化和安全方面有著非常重要且廣泛的應用,以下面C代碼為例,來簡單介紹別名分析在代碼優(yōu)化方面的應用[2]。

intfoo(int__attribute__((address_space(0)))*a,
int__attribute__((address_space(1)))*b){
*a=42;
*b=20;
return*a;
}

__attribute__屬性指定了變量a指向地址0,變量b指向地址1。我們知道在ARM架構中,地址0和地址1是完全不同的,修改地址0中的內存永遠不會修改地址1中的內存。以下為該函數可能生成的LLVM IR信息:

definei32@foo(i32addrspace(0)*%a,i32addrspace(1)*%b)#0{
entry:
storei3242,i32addrspace(0)*%a,align4
storei3220,i32addrspace(1)*%b,align4
%0=loadi32,i32*%a,align4
reti32%0
}

第一個store將42存儲到變量a指向的地址,第二個store指令將20存儲到變量b指向的地址。%0 = ... 指向的行將變量a中的值加載到一個臨時變量0中,并在最后一行返回該臨時變量0。

上述代碼是未對foo函數進行優(yōu)化的情況,下面我們考慮對foo函數進行優(yōu)化。

我們優(yōu)化后的代碼可能如下:刪除了load指令對應的行,最后一行直接返回了常量42。

definei32@foo(i32addrspace(0)*%a,i32addrspace(1)*%b)#0{
entry:
storei3242,i32addrspace(0)*%a,align4
storei3220,i32addrspace(1)*%b,align4
reti3242
}

然而,我們進行優(yōu)化的時候需要仔細一些,因為上述優(yōu)化僅在a和b指向的地址不會相互影響時有效。例如:當我們給foo函數傳遞的指針相互影響時:

inti=0;
intresult=foo(&i,&i);

在未開啟優(yōu)化的版本中,變量i將先被設置為42,然后被設置為20,最后返回20。然而,在優(yōu)化版本中,雖然我們執(zhí)行了兩次store操作依次將42、20賦值給變量i,但是返回值是42,而不是20。因此優(yōu)化版本破壞了foo函數本身的行為。

如果應用了別名分析,編譯器能夠合理地執(zhí)行上述優(yōu)化。在執(zhí)行優(yōu)化前判斷入參a和b是否為別名,如果是別名,則不執(zhí)行刪除load指令對應行的操作,否則執(zhí)行刪除操作。

4.2 實現

本文以LLVM16.0.0版本為參考,從代碼接口入手,帶領大家學習別名分析的代碼實現。

LLVM AliasAnalysis類是LLVM系統(tǒng)中客戶使用和別名分析實現的主要接口,或者說一個“基類” 。除了簡單的別名分析信息外,這個類還聲明了Mod/Ref信息,從而使強大的分析和轉換能夠很好地協(xié)同工作。

源碼參考鏈接:AliasAnalysis.h[3]、AliasAnalysis.cpp[4]。

4.2.1 基礎知識

MemoryLocation:LLVM中對內存地址的描述,主要應用在別名分析中,我們需要掌握該類中三個屬性:

404e26d6-334d-11ed-ba43-dac502259ad0.png

其中,Ptr表示內存開始地址,Size表示內存大小,AATags是描述內存位置別名的metadata節(jié)點集合 。

4.2.2 AliasAnalysis Class概覽

AliasAnalysis類定義了各種別名分析實現應該支持的接口。這個類導出兩個重要的枚舉:AliasResult和ModRefResult,它們分別表示別名查詢或mod/ref查詢的結果。

1、關鍵代碼如下,AliasAnalysis為AAResults類別名:

406343e0-334d-11ed-ba43-dac502259ad0.png

2、AliasResult關鍵代碼如下:

407fbb9c-334d-11ed-ba43-dac502259ad0.png

其中NoAlias表示兩個內存對象沒有任何重疊區(qū)域;MayAlias表示兩個指針可能指向同一對象;PartialAlias表示兩個內存對象對應的地址空間有重疊;MustAlias表示兩個內存對象總是從同一位置開始。

3、ModRefResult關鍵代碼

40a5a3c0-334d-11ed-ba43-dac502259ad0.png

其中NoModRef表示訪問內存的操作既不會修改該內存也不會引用該內存;Ref表示訪問內存的操作會可能引用該內存;Mod表示訪問內存的操作可能會修改該內存;ModRef表示訪問內存的操作既可能引用該內存也可能修改該內存。

alias接口

其接口定義如下:

40ba2f66-334d-11ed-ba43-dac502259ad0.png

別名方法是用于確定兩個MemoryLocation對象是否相互別名的主要接口。它接受兩個MemoryLocation對象作為輸入,并根據需要返回MustAlias、PartialAlias、MayAlias或NoAlias。與所有AliasAnalysis接口一樣,alias方法要求其入參的兩個MemoryLocation對象定義在同一個函數中,或者至少有一個值是常量。

其接口實現如下:

40cdeb0a-334d-11ed-ba43-dac502259ad0.png

getModRefInfo 接口

getModReInfo方法返回關于給定的指令執(zhí)行是否可以讀取或修改給定內存位置的信息。Mod/Ref信息具有保守性:如果一條指令可能讀或寫一個位置,則返回ModRef。其接口定義眾多,我們以如下接口為例來進行學習。

40fef858-334d-11ed-ba43-dac502259ad0.png

其接口實現如下:

411b6b32-334d-11ed-ba43-dac502259ad0.png

從上述代碼可知,處理共分為四步:

(1)遍歷AAs,如果發(fā)現其任一結果是NoModRef,則直接返回,對應代碼行228-234;

(2)調用節(jié)點(call)操作中是否訪問了一個在LLVM IR中無法訪問的地址,如果是的話,直接返回NoModRef,否則獲取其調用節(jié)點的ModRefInfo信息,對應代碼行239-240;

(3)處理調用節(jié)點中指針入參的ModRefInfo信息,如果發(fā)現是NoModRef,則直接返回NoModRef,否則將ModRefInfo信息和之前的結果合并,對應代碼行247-266;

(4)如果getModRefInfo函數中的入參Loc指定的內存地址具有常量屬性并且ModRefInfo信息包含Mod,則調用節(jié)點一定不會修改Loc內存,因此需要將Ref屬于與之前的結果做邏輯與操作,對應代碼行271-272。

4.2.3 LLVM中已經實現的別名分析

-basic-aa pass

-basic-aa pass是一種激進的本地分析,它提供許多重要的事實信息[5]:

不同的全局變量、堆棧分配和堆分配永遠不能別名。

全局變量、棧分配的變量和堆分配變量永遠不會和空指針別名。

結構體中的不同字段不能別名。

同一數組,索引不同的兩個對象不能別名。

許多通用的標準C庫函數從不訪問內存或只讀取內存。

-globals-aa pass

這個pass實現了一個簡單的對內部全局變量(該變量的地址沒有被獲取過)進行上下文敏感的mod/ref分析和別名分析。如果某個全局變量的地址沒有被獲取,則該pass可以得出如下結論:沒有指針作為該全局變量的別名。該pass還會識別從不訪問內存或從不讀取內存的函數。這允許某些指定的優(yōu)化(例如GVN)完全消除調用指令。

這個pass的真正威力在于它為調用指令提供了上下文敏感的mod/ref信息。這使優(yōu)化器清楚的了解到對于某些函數的調用不會破壞或讀取全局變量的值,從而允許消除加載和存儲指令。

Note:該pass在使用范圍上有一定限制,僅支持沒有被取過地址的全局變量,但是該pass分析速度非???。

除了上述pass外,LLVM中還實現了cfl-steens-aa、cfl-anders-aa、tbaa、scev-aa。目前LLVM中O1,O2,O3優(yōu)化默認開啟的別名分析是basic-aa,globals-aa和tb-aa。

5.寫在最后

編譯器技術從20世紀50年代起,已經發(fā)展了近70年的歷史,但是編譯器技術發(fā)展到今天,依然是一個非常熱門的技術,各大硬件廠商都在開發(fā)自己的編譯器,包括因特爾推出的Inter C++、ARM公司推出的armclang以及華為推出的畢昇編譯器等,且上述三款編譯器都是基于LLVM開發(fā)。

編譯器技術是一門龐大且繁雜的技術,對于初學者來說,這條學習之路道阻且長,盼那些熱愛這門技術的趕路人能夠行而不輟,未來可期。

審核編輯:彭靜
聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 數據
    +關注

    關注

    8

    文章

    6760

    瀏覽量

    88618
  • 代碼
    +關注

    關注

    30

    文章

    4697

    瀏覽量

    68083
  • 編譯器
    +關注

    關注

    1

    文章

    1608

    瀏覽量

    48977

原文標題:編譯器優(yōu)化那些事兒(6):別名分析概述

文章出處:【微信號:openEulercommunity,微信公眾號:openEuler】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    編譯器優(yōu)化那些事兒(6):別名分析概述

    1.簡介別名分析編譯器理論中的一種技術,用于確定存儲位置是否可以以多種方式訪問。如果兩個指針指向相同的位置,則稱這兩個指針為別名。但是,它不能與指針
    發(fā)表于 09-15 14:09

    C編譯器的設計文檔與源代碼

    C-編譯器的設計文檔與源代碼:本壓縮包包含了C-編譯器的設計文檔與源代碼,供學習參考。  整體框架. 3 詞法分析. 3 Class CTokeniz
    發(fā)表于 02-09 11:13 ?45次下載

    ICC AVR編譯器的安裝與使用

    ICCAVR編譯器的安裝、運行、破解、使用 用ICCAVR編譯器產生初始化程序和程序框架
    發(fā)表于 07-09 18:06 ?258次下載

    基于CoSy的編譯器開發(fā)的研究

    CoSy是ACE公司開發(fā)的編譯器構造框架[1]。它提供共享工具和引擎來構造編譯器,編譯器開發(fā)者只專注于目標機相關代碼的開發(fā)。CoSy框架生成的編譯器具有可擴展性和可移植性??梢愿鶕?/div>
    發(fā)表于 08-19 17:49 ?0次下載
    基于CoSy的<b class='flag-5'>編譯器</b>開發(fā)的研究

    PICC編譯器下載

    PICC編譯器下載
    發(fā)表于 05-25 17:44 ?168次下載

    NEC編譯器培訓手冊

    NEC編譯器培訓手冊,開發(fā)者可根據功能要求對編譯器進行設計。
    發(fā)表于 05-03 14:23 ?15次下載

    編譯器是如何工作的_編譯器的工作過程詳解

    隨著計算機的發(fā)展,編譯器已經發(fā)揮著十分重要的作用。本文主要介紹了編譯器的種類、編譯器的工作原理以及編譯器工作的具體操作過程及步驟詳解。
    發(fā)表于 12-19 12:54 ?1.6w次閱讀

    編譯器原理到底是怎樣的帶你簡單的了解編譯器原理

    編程語言是怎樣工作的 理解編譯器內部原理,可以讓你更高效利用它。按照編譯的工作順序,逐步深入編程語言和編譯器是怎樣工作的。本文有大量的鏈接、樣例代碼和圖表幫助你理解編譯器。
    的頭像 發(fā)表于 12-23 17:25 ?1.1w次閱讀

    既然C編譯器是C語言寫,那么第一個C編譯器是怎樣來的?

    既然C編譯器是C語言寫的,那第一個C編譯器是怎樣來的?
    的頭像 發(fā)表于 02-25 15:47 ?3058次閱讀

    Verilog HDL 編譯器指令說明

    Verilog HDL 編譯器指令 復雜一點的系統(tǒng)在進行設計或者驗證時,都會用到一些編譯器指令,那么什么是編譯器指令? ? Verilog HDL編譯器指令由重音符(‘)開始。在Ver
    的頭像 發(fā)表于 11-03 09:31 ?3514次閱讀
    Verilog HDL <b class='flag-5'>編譯器</b>指令說明

    GH集成開發(fā)環(huán)境和編譯器

    說實話,以前也用過正版的編譯器,我記得之前用過正版的IAR編譯器license也沒有多貴,而最近用了個10萬一個license的編譯器編譯嵌入式代碼,因為對功能安全有要求,而這個Gre
    的頭像 發(fā)表于 03-16 17:08 ?1649次閱讀

    交叉編譯器安裝教程

    交叉編譯器中“交叉”的意思就是在一個架構上編譯另外一個架構的代碼,相當于兩種架構“交叉”起來了。Ubuntu 自帶的 gcc 編譯器是針對 X86 架構的,而我們現在要編譯的是 ARM
    的頭像 發(fā)表于 09-29 09:12 ?3364次閱讀

    領域編譯器發(fā)展的前世今生

    近年來,隨著GPU和DSA架構在不同領域的廣泛應用,特別是AI系統(tǒng)相關技術的飛速發(fā)展,對于編譯器的需求越來越強烈。編譯器已經從一個相對小眾的研究領域,變?yōu)閷W界和業(yè)界都高度關注并大量投入的方向
    的頭像 發(fā)表于 02-03 10:37 ?1566次閱讀

    編譯器優(yōu)化那些事兒:別名分析概述

    別名分析編譯器理論中的一種技術,用于確定存儲位置是否可以以多種方式訪問。如果兩個指針指向相同的位置,則稱這兩個指針為別名。
    的頭像 發(fā)表于 05-24 16:16 ?496次閱讀
    <b class='flag-5'>編譯器</b>優(yōu)化那些事兒:<b class='flag-5'>別名分析</b>概述

    人工智能編譯器與傳統(tǒng)編譯器的區(qū)別

    人工智能編譯器(AI編譯器)與傳統(tǒng)編譯器在多個方面存在顯著的差異。這些差異主要體現在設計目標、功能特性、優(yōu)化策略、適用范圍以及技術復雜性等方面。以下是對兩者區(qū)別的詳細探討,旨在全面解析其內在差異。
    的頭像 發(fā)表于 07-17 18:19 ?1464次閱讀