? 本文主要分享如何快速上手ARM匯編開發(fā)的經(jīng)驗(yàn)、匯編開發(fā)中常見的Bug以及Debug方法、用的Convolution Dephtwise算子的匯編實(shí)現(xiàn)相對于C++版本的加速效果三方面內(nèi)容。 ?

? 01前言

神經(jīng)網(wǎng)絡(luò)模型能夠在移動端實(shí)現(xiàn)快速推理離不開高性能算子，直接使用ARM匯編指令來進(jìn)行算子開發(fā)無疑會大大提高算子的運(yùn)算性能。初次接觸匯編代碼可能會覺得其晦澀難懂然后望而卻步，但ARM匯編開發(fā)一旦入門就會覺得語言優(yōu)美簡潔，如果再切換到ARM INTRISIC指令開發(fā)反而覺得沒有直接寫匯編碼來的方便。我會在第一節(jié)分享純小白如何快速上手ARM匯編開發(fā)的經(jīng)驗(yàn)，第二節(jié)會列舉在匯編開發(fā)中常見的Bug以及Debug方法，第三節(jié)會展示常用的Convolution Dephtwise算子的匯編實(shí)現(xiàn)相對于C++版本的加速效果。如果你已經(jīng)能很熟練地使用ARM匯編指令進(jìn)行開發(fā)了，可以跳過第一節(jié)。

? 02從簡單函數(shù)上手

? ? 學(xué)習(xí)匯編開發(fā)重要的一點(diǎn)是通過學(xué)習(xí)現(xiàn)有函數(shù)的匯編代碼來實(shí)現(xiàn)自己的需求

我寫的第一個匯編算子是MaxPooling算子，算子本身的計(jì)算過程非常簡單。但當(dāng)我開始實(shí)現(xiàn)MaxPooling的匯編代碼時，我不知道第一行代碼怎么寫，不知道開頭和結(jié)尾怎么寫，不知道中間的計(jì)算邏輯怎么寫。當(dāng)時我就在MNN庫的source文件夾下面找到了一份邏輯簡單的、自己非常熟悉的Relu算子當(dāng)做參照來實(shí)現(xiàn)MaxPooling. 之所以我推薦用一個邏輯簡單的、自己非常熟悉的算子當(dāng)做學(xué)習(xí)匯編的模版，是因?yàn)楫?dāng)算子的計(jì)算邏輯簡單時，我們才能把注意力放在匯編函數(shù)的聲明、傳參、讀取數(shù)據(jù)、存儲結(jié)果、返回等等這些大的流程上面，至于內(nèi)部的函數(shù)實(shí)現(xiàn)（如何計(jì)算一行數(shù)據(jù)的最大值，如何去計(jì)算一個寄存器中所有數(shù)據(jù)的累加和等等）可以暫時不去關(guān)注。學(xué)習(xí)一個新的東西時，我們找的例子模版不能過于復(fù)雜，因?yàn)檫@會導(dǎo)致我們將注意力放在例子本身的實(shí)現(xiàn)細(xì)節(jié)中，而忽略了如何去入門，這樣會增加我們的學(xué)習(xí)成本。 ?

匯編函數(shù)的開頭與結(jié)尾

函數(shù)定義以asm_function開頭，后加函數(shù)名（以MNNAvgPoolInt8 ARM64為例）：

?

asm_function MNNAvgPoolInt8
// 加上函數(shù)的傳參注釋，方便后續(xù)對照使用對應(yīng)的寄存器
// void MNNAvgPoolInt8(int8_t* dst, int8_t* src, size_t outputWidth,
// size_t inputWidth, size_t kernelx, size_t kernely, size_t stridesx,
// ssize_t paddingx, ssize_t factor);
// Auto load: x0: dst, x1: src, x2: outputWidth, x3: inputWidth,
// x4: kernelx, x5: kernely, x6: stridesx, x7: paddingx


// Load from sp:
// w8: factor

?

傳參：ARM64 用于傳參的寄存器有8個：x0-x7. 如果函數(shù)的參數(shù)大于8，就需要使用sp寄存器讀取剩余參數(shù)。例如AvgPoolInt8算子中的第9個參數(shù)factor讀?。?/p>

?

// x8寄存器存儲參數(shù)factor的值，不是必須使用x8寄存器，用其他寄存器也是可以的。
ldr x8, [sp, #0]

? ARM寄存器使用不當(dāng)會導(dǎo)致程序crash。這里總結(jié)了ARM32和AMR64的寄存器基本使用規(guī)則。ARM32中通用寄存器和向量寄存器都有16個，每個向量寄存器的最大使用長度是128位。ARM32中用于傳參的寄存器有4個：r0-r3。ARM32中r13寄存器就是sp寄存器，指向棧頂；r14寄存器也叫l(wèi)r寄存器，存儲函數(shù)的返回值地址；r15寄存器也叫pc寄存器，存儲將要執(zhí)行的下一條指令的地址。在進(jìn)行匯編開發(fā)時，一般不使用r13和r15寄存器來存儲臨時變量。r9寄存器的使用在各個平臺上可能不同，為了防止出錯，一般也不用來存儲臨時變量。當(dāng)不需要使用r14存儲返回值地址的信息時，也可以使用其存儲臨時變量。下圖中我總結(jié)了ARM32中寄存器的基本使用規(guī)則，關(guān)于各寄存器更加詳細(xì)的介紹參考。 ?

?

ARM64中通用寄存器和向量寄存器的個數(shù)比ARM32多一倍，有32個。ARM64中向量寄存器的使用更加靈活，可以8bit,16bit,32bit,64bit使用。例如，v0表示128位的向量寄存器，d0,s0,h0分別表示v0的低64位，32位，16位。注意，d1,s1,h1表示v1寄存器的低64位，32位，16位，而不是緊接著v0的第二個相應(yīng)位。ARM64的寄存器使用見下圖。

? 我們可以用浮點(diǎn)操作指令把向量寄存器中的數(shù)當(dāng)做標(biāo)量來進(jìn)行計(jì)算，需要注意在ARMV8中浮點(diǎn)操作指令不支持對16bit的浮點(diǎn)數(shù)進(jìn)行計(jì)算，僅支持做16bit和32bit, 64bit之間的轉(zhuǎn)換。 ?

fadd Sd, Sn, Sm   // 32bit Single precision
fsub Dd, Dn, Dm  // 64bit Double precision
fcvt Sd, Hn          // half-precision to single-precision
fcvt Dd, Hn          // half-precision to double-precision
fcvt Hd, Sn          // single-precision to half-precision
fcvt Hd, Dn          // double-precision to half-precision

?

?

對上圖中的“用完恢復(fù)”寄存器的使用：一些復(fù)雜的函數(shù)需要的向量寄存器或者通用寄存器可能會非常多，那就需要我們在開頭加載這些寄存器，不然會報(bào)錯segment fault.加載方法如下：

?

// d8-d15表示使用v8-v15這8個寄存器的64位, (2* 64)/8=16,
// 這就是每次sp移位時(#16*i)中16的來源。
stp d14, d15, [sp, #(-16 * 9)]!
stp d12, d13, [sp, #(16 * 1)]
stp d10, d11, [sp, #(16 * 2)]
stp d8,  d9,  [sp, #(16 * 3)]
stp x27, x28, [sp, #(16 * 4)]
stp x25, x26, [sp, #(16 * 5)]
stp x23, x24, [sp, #(16 * 6)]
stp x21, x22, [sp, #(16 * 7)]
stp x19, x20, [sp, #(16 * 8)]

?

?

在函數(shù)的結(jié)尾需要釋放這些寄存器：

?

ldp x19, x20, [sp, #(16 * 8)]
ldp x21, x22, [sp, #(16 * 7)]
ldp x23, x24, [sp, #(16 * 6)]
ldp x25, x26, [sp, #(16 * 5)]
ldp x27, x28, [sp, #(16 * 4)]
ldp d8,  d9,  [sp, #(16 * 3)]
ldp d10, d11, [sp, #(16 * 2)]
ldp d12, d13, [sp, #(16 * 1)]
ldp d14, d15, [sp], #(16 * 9)
ret // 最后需加上ret返回

? ARM32中寄存器的數(shù)量只有ARM64的一半，自動傳參的寄存器僅r0-r3這四個寄存器，其他寄存器的加載方式和ARM64也不同，我們依然以MNNAvgPoolInt8為例，代碼的解釋和新手閉坑的地方我直接在下面的注釋中寫明。

// 函數(shù)定義
asm_function MNNAvgPoolInt8
// void MNNAvgPoolInt8(int8_t* dst, int8_t* src, size_t outputWidth,
// size_t inputWidth, size_t kernelx, size_t kernely, size_t stridesx,
// ssize_t paddingx, ssize_t factor);
// Auto load: r0: dst, r1: src, r2: outputWidth, r3: inputWidth
// r4: kernelx, r5: kernely, r7: stridesx, r8: paddingx, lr: factor


// 其他寄存器加載, 注意lr寄存器每次必須被push進(jìn)來(可以不使用)，不然會報(bào)錯segment fault.
push {r4-r8, r10-r11, lr}
// 上一行push了8個寄存器，那么sp指針會向低地址移動(8*4=32)個字節(jié)（ARM32每個指針占4個字節(jié)），
// 所以第五個參數(shù)“kernelx”加載時需要將sp的地址加(#32).
// 虛擬內(nèi)存中棧是從高地址向低地址擴(kuò)展的，而函數(shù)傳參是從右往左傳去棧中的，
// 所以后面的參數(shù)地址會比前面的高，即相對sp寄存器的地址增加的更多。
ldr r4, [sp, #32] // kernelx
ldr r5, [sp, #36] // kernely
ldr r7, [sp, #40] // stridesx
ldr r8, [sp, #44] // paddingx
ldr lr, [sp, #48] // factor


// 加載向量寄存器一定要放在利用sp寄存器來讀取所有函數(shù)參數(shù)之后，
// 否則不能正常讀取函數(shù)參數(shù)
vpush?{q4-q7}

?

ARM32 結(jié)尾對寄存器的釋放

?

// 不需要pop lr寄存器，但是必須pop pc寄存器。
// ARM32結(jié)尾不需要寫 ret, 這和ARM64不同。
vpop {q4-q7}
pop {r4-r8, r10-r11, pc}

?

??核心功能的實(shí)現(xiàn)

? 寫匯編代碼之前，我們一定要先實(shí)現(xiàn)C++版本的代碼，保證C++版本的算子在ARM移動端的計(jì)算結(jié)果是正確的。這樣做有兩個目的：第一，保證我們對算子的理解是正確并清晰的，否則寫匯編算子就是浪費(fèi)時間；第二，為匯編算子的輸出結(jié)果提供標(biāo)準(zhǔn)答案，因?yàn)橥瑯拥?C++ 代碼在不同的平臺上的計(jì)算結(jié)果可能會略有不同(但差異不會很大），我們需要保證匯編版本的算子和C++版本的算子計(jì)算結(jié)果在ARM平臺上完全一致。 ?

匯編代碼中條件判斷和分支跳轉(zhuǎn)

? MaxPooling算子通過遍歷局部區(qū)域的所有元素，進(jìn)而找到區(qū)域內(nèi)的最大值。這就涉及到循環(huán)指令、地址跳轉(zhuǎn)指令和比較兩個向量寄存器中對應(yīng)元素。關(guān)于指令的解釋我直接在代碼注釋中寫明。 ?

比較兩個向量寄存器中對應(yīng)元素的大小

?

/*
smax, smin 比較整型數(shù)數(shù)據(jù)的大小
ARM匯編有符號整數(shù)的指令一般以s開頭(signed int)
無符號整數(shù)的指令一般以u開頭(unsigned int)
浮點(diǎn)數(shù)據(jù)的指令一般以f開頭(float)
*/


// 比較v0和v1寄存器中的16個int8_t數(shù)據(jù),
// 并將對應(yīng)位置上的較大值存儲在v2的相應(yīng)位置上
// b 表示以8位來讀取數(shù)據(jù)，相應(yīng)的匯編中 h:16位, s:32位, d:64位
smax v2.16b, v0.16b, v1.16b
smin v10.4s, v11.4s, v12.4s //比較v11和v12的4個int32_t數(shù)據(jù)的大小

?

?

循環(huán)執(zhí)行某一段代碼

如果需要在ARM匯編中循環(huán)執(zhí)行一段代碼，那我們需要自定義一個符號來標(biāo)記這一段代碼。以MaxPooling算子為例，假設(shè)每一個像素點(diǎn)含有16個Channel，我們需要得到被kernel覆蓋到的9個像素點(diǎn)上對應(yīng)Channel的最大值，即重復(fù)執(zhí)行比較指令9次。例如用Loop來標(biāo)記我們需要循環(huán)的代碼段：

?

1. mov w7, #-0x80 // 給通用寄存器賦值-128，即int8_t類型的最小值
2. dup v0.16b, w7 // 初始化v0, v0中存儲了16個-128
3. mov x10, #9    // 計(jì)數(shù)
// 循環(huán)
Loop:
3. ld1 {v1.16b}, [x0] // 從地址x0中加載16個int8的數(shù)據(jù)到v1寄存器，與v0做比較
4. smax v0.16b, v0.16b, v1.16b // 用v0記錄最終的比較結(jié)果
5. add x0, x0, #1      // 移動像素點(diǎn)的地址，這里我們假設(shè)9個像素點(diǎn)是連續(xù)的
6. sub x10, x10, #1    // 比較完一個像素點(diǎn)的16個Channel大小后，計(jì)數(shù)減1
7. cmp x10, #0         // cmp是compare的縮寫：比較x10和0的大小
8. bgt Loop            // bgt是branch greater than的縮寫，滿足條件就跳到分支Loop執(zhí)行
// 循環(huán)執(zhí)行結(jié)束
9. st1 {v0}, [x1]       // 存儲寄存器v0中的16個int8_t數(shù)據(jù)到地址x1中


// ARM 匯編代碼是按照從上到下的順序來執(zhí)行的，
// 所以跳出Loop不需要額外的指令來表示結(jié)束該分支
// 當(dāng)不滿足x10>0時，會直接執(zhí)行第9行代碼

? ??如何查找需要的指令 ?

靈活地運(yùn)用各種匯編指令往往能提高算子性能。

利用現(xiàn)成的匯編代碼查找指令

? 當(dāng)我們閱讀一些匯編代碼時，根據(jù)匯編指令去查詢其功能是非常容易的，甚至根據(jù)指令名我們可以猜測出他的功能。但是當(dāng)我們第一次寫匯編代碼時，想知道實(shí)現(xiàn)某個功能可以使用哪些指令往往很難。此時最關(guān)鍵的一點(diǎn)，需要我們思考哪個函數(shù)中會用到我將要實(shí)現(xiàn)的功能，然后去參考他的匯編實(shí)現(xiàn)過程。比如寫Pooling算子的匯編代碼時不知道如何去進(jìn)行循環(huán)代碼段的編寫，我們就可以參考矩陣乘算子的匯編代碼去學(xué)習(xí)分支跳轉(zhuǎn)，寄存器的比較等指令。當(dāng)我們不知道如何用匯編指令去實(shí)現(xiàn)浮點(diǎn)數(shù)轉(zhuǎn)整數(shù)的四舍五入時，MNN中現(xiàn)成的Float2Int8函數(shù)一定會有相應(yīng)的指令實(shí)現(xiàn)這個功能。當(dāng)我們編寫了越來越多的匯編代碼，會接觸到更多的匯編指令，解決問題的思路和視野也更開闊。 ?

利用關(guān)鍵詞在ARM官網(wǎng)查找指令

ARM官網(wǎng)列舉了所有匯編指令的用法，其中ARM64的指令手冊比ARM32更易查找和理解。一般ARM64的指令在ARM32系統(tǒng)都能找到對應(yīng)的等效指令。偶爾我們也需要ARM Intrisic指令來完成一些簡單函數(shù)的開發(fā)，Intrisic指令可以參考。利用好功能的關(guān)鍵詞能提高查找指令的速度。例如某次編程中我需要查找哪些指令能實(shí)現(xiàn)“int8+int16->int16"的功能，顯然關(guān)鍵詞是"add". 官網(wǎng)中會列舉適用于各種場景的向量加法指令，很快就可以定位到"saddw v0.8h, v1.8h, v2.8b"指令。

03ARM匯編Debug方法和常見錯誤列舉

?利用好“打印printf”

匯編代碼的調(diào)試一直是個難題，不能像C++代碼那樣一步步Debug查看變量的值，只能通過在函數(shù)調(diào)用的外層加打印的方式來查看匯編代碼的執(zhí)行結(jié)果。不過只要我們能利用好打印，匯編代碼的BUG排查就能簡單不少！具體來說，如果我們需要查看某個中間變量的值，我們可以在代碼內(nèi)部用返回值地址來存儲該值，從而我們可以在匯編代碼的外部打印該地址存儲的內(nèi)容，這樣間接地檢查代碼執(zhí)行的邏輯是否符合預(yù)期。

??函數(shù)傳參錯誤

函數(shù)傳參錯誤非常容易被忽視，因?yàn)檫@個錯誤很少會直接報(bào)錯"segment fault"，而是發(fā)現(xiàn)匯編算子的結(jié)果和C++版本不一致時，經(jīng)過一步步排查才發(fā)現(xiàn)傳參就出現(xiàn)了錯誤。畢竟我們發(fā)現(xiàn)結(jié)果錯誤時，更習(xí)慣于去檢查匯編代碼中最復(fù)雜的邏輯，不太會想到代碼開頭的函數(shù)傳參就已經(jīng)錯了。目前為止，我遇到過的傳參錯誤就只有以下兩種：

1、除了整型以外的數(shù)據(jù)傳參應(yīng)該用指針傳入，而不是直接傳入?yún)?shù)值。浮點(diǎn)參數(shù)傳遞方式與編譯器及參數(shù)配置相關(guān)，可能不同平臺下傳遞方式不一樣。如果直接浮點(diǎn)數(shù)值傳參，帶來的結(jié)果有可能是：浮點(diǎn)參數(shù)后面的參數(shù)數(shù)值都是前一個參數(shù)的數(shù)據(jù)，也就是發(fā)生了傳參的偏移，導(dǎo)致計(jì)算結(jié)果對不上；如果恰巧你需要從某個參數(shù)中l(wèi)oad數(shù)據(jù)，該參數(shù)的值受到了浮點(diǎn)參數(shù)錯誤傳遞的影響，那有可能會報(bào)segment fault的錯誤。

?

// 正確傳參，用指針傳遞浮點(diǎn)常數(shù)para0
 void func(float* para0, float* dst)


// 錯誤傳參，直接傳入常數(shù)para0
void func(float para0, float* dst)

? 2、傳參寄存器使用錯誤
ARM64 自動傳參的寄存器有8個：x0-x7，ARM32 自動傳參的寄存器有4個: r0-r3。如果參數(shù)個數(shù)大于8（4），就需要從sp寄存器的相對位置來load參數(shù)。

asm_function MNNAvgPoolInt8
// 加上函數(shù)的傳參注釋，方便后續(xù)對照使用對應(yīng)的寄存器
// void MNNAvgPoolInt8(int8_t* dst, int8_t* src, size_t outputWidth,
// size_t inputWidth, size_t kernelx, size_t kernely, size_t stridesx,
// ssize_t paddingx, ssize_t factor);
// Auto load: x0: dst, x1: src, x2: outputWidth, x3: inputWidth,
// x4: kernelx, x5: kernely, x6: stridesx, x7: paddingx


// Load from sp:
// w8: factor

?

?

3、整型參數(shù)建議使用ssize_t和size_t傳參

定義一個函數(shù)：void func(int8_t* dst, int8_t* src, float* params0, float* params1, int width, int height, int kernelx, int kernely, int needBroadcast)
按照前面的介紹，第9個參數(shù)needBroadcast應(yīng)該由sp寄存器來加載，如：ldr x8, [sp, #0]，如果我們需要比較needBroadcast和0的大小，寫成：cmp x8, #0，無論x8是否為0，代碼的判斷結(jié)果都會是false.除非將判斷語句寫成：cmp w8, #0. 出現(xiàn)這種問題的原因在于，ssize_t和size_t這兩種類型，ARM64和ARM32會將其分別看做是64位和32位的數(shù)據(jù)，而對于int類型的數(shù)據(jù)，ARM64和ARM32上都會是32位的數(shù)據(jù)，而ARM64的通用寄存器以x來使用是64位的（即x1,x2...），以w來使用才是32位的（即w1,w2...)。所以要比較x8與0的大小關(guān)系，應(yīng)是：cmp,w8,#0.

對于上述問題的更好的解決辦法是，函數(shù)聲明時將needBroadcast參數(shù)的類型定義成ssize_t，因?yàn)樵搮?shù)的取值可能是-1,1,0， 我們將其定義成有符號類型。在匯編代碼中再次使用 cmp x8, #0來比較結(jié)果就是正確的了，當(dāng)然此時我們還是用w8和0比較的話，結(jié)果也是正確的。

??ARM32 向量寄存器和參數(shù)加載的順序問題

? 在匯編開發(fā)中我遇到過這樣的問題，定義一個函數(shù)如下：

// void MNNAvgPoolInt8(int8_t* dst, int8_t* src, size_t outputWidth,
// size_t inputWidth, size_t kernelx, size_t kernely, size_t stridesx,
// ssize_t paddingx, ssize_t factor);
asm_function MNNAvgPoolInt8
// Auto load: r0: dst, r1: src, r2: outputWidth, r3: inputWidth
// Load from sp: r4: kernelx, r5: kernely, r7: stridesx, r8: paddingx, lr: factor
2. push {r4-r8, r10-r11, lr}
3. vpush {q4-q6}


4. ldr r4, [sp, #32]
5. ldr r5, [sp, #36]
6. ldr r7, [sp, #40]
7. ldr r8, [sp, #44]
8.?ldr?lr,?[sp,?#48]???????//?lr:?factor

?

這樣可能不會出現(xiàn)報(bào)錯segment fault，但是參數(shù)的加載結(jié)果是錯的。原因在于第3行vpush應(yīng)該在通過sp加載完所有的函數(shù)參數(shù)之后，而不是在此之前。因?yàn)閜ush了8個通用寄存器入棧之后，再push向量寄存器入棧，那么函數(shù)參數(shù)相對于sp寄存的位置就不再是(8x4=32). 相對位置的偏移發(fā)生了變化。第3行的代碼應(yīng)該在第8行后面。 ?

??ARM64 通用寄存器的使用問題

? 在ARM64中給通用寄存器賦整型數(shù)值

// 通用寄存器的賦值只能用32位來使用寄存器
mov w10, #0 // right
mov x10, #0 // error
// 后續(xù)計(jì)算中要使用x10來進(jìn)行加減乘的計(jì)算，需要將w10擴(kuò)展成x10:
uxtw x10, w10 // w10中32位數(shù)據(jù)在x10的低32位中保持不變，x10的高32位填充為0.

? sub, add等指令只能對整型數(shù)據(jù)操作，浮點(diǎn)類型數(shù)據(jù)需要使用fsub, fadd等

fmov v1.4s, #1.0
fmov v2.4s, #0.2
fsub v1.4s, v1.4s, v2.4s

?

?

??四舍五入的問題

ARM32和ARM64中浮點(diǎn)數(shù)取整的方式不一樣。ARM32中浮點(diǎn)數(shù)轉(zhuǎn)換成整數(shù)的指令（vcvt.s32.f32）是向負(fù)無窮取整的，在ARM32中沒有四舍五入的取整指令。需要在ARM32中實(shí)現(xiàn)四舍五入，可以這樣做：

?

//對寄存器q3中的4個浮點(diǎn)數(shù)據(jù)做四舍五入取整
// q3: -1.4, 4.5, 1.1, -2.7 -> q3: -1, 4, 1, -3
vmov.f32 q1, #0.5
vmov.f32 q2, #-0.5
vcgt.f32 q12, q3, #0
vbsl.f32 q12, q1, q2  // bitwise select.
vadd.f32 q13, q12, q3
vcvt.s32.f32 q3, q13

? ARM64提供的取整指令更加靈活方便，有：

// q10:  -1.4, 4.5, 1.1, -2.7
fcvtas q1, q10 // q1: -1, 5, 1, -3 就近取整
fcvtzs q2, q10 // q2: -1, 4, 1, -2 向0取整
fcvtms q3, q10 // q3: -2, 4, 1, -3 向負(fù)無窮取整
fcvtps q4, q10 // q4: -1, 5, 2, -3 向正無窮取整
fcvtns q4, q10 // q4: -2, 4, 2, -2 向最近的偶數(shù)取整

?

?

??整型數(shù)據(jù)和浮點(diǎn)數(shù)據(jù)進(jìn)行數(shù)學(xué)運(yùn)算的問題

整型數(shù)據(jù)與浮點(diǎn)數(shù)據(jù)進(jìn)行相加或相乘等數(shù)學(xué)運(yùn)算之前，一定要先將整型數(shù)據(jù)轉(zhuǎn)換成浮點(diǎn)數(shù)據(jù)再進(jìn)行數(shù)學(xué)運(yùn)算，否則計(jì)算結(jié)果會出錯。該過程經(jīng)常出現(xiàn)在Int8量化算子的開發(fā)中，往往是量化算子很難消除的計(jì)算負(fù)擔(dān)。用Binary multiply的Int8量化算子舉例說明該過程：

?

// Int8 量化的乘法算子，輸入和輸出均是Int8類型，但考慮到int8xint8會可能會導(dǎo)致越界，
// 在量化算子的實(shí)現(xiàn)過程中會將兩個輸入數(shù)據(jù)分別轉(zhuǎn)換成Float32數(shù)據(jù)之后相乘，
// 再將Float32的結(jié)果量化到Int8類型.
sxtl v0.8h, v0.8b // int8x8_t -> int16x8_t
sxtl v1.8h, v1.8b // int8x8_t -> int16x8_t


sxtl v2.4s, v0.4h  // v0的低64位數(shù)據(jù)：int16x4_t -> int32x4_t
sxtl2 v3.4s, v0.8h // v0的高64位數(shù)據(jù)：int16x4_t -> int32x4_t
sxtl v4.4s, v1.4h
sxtl2 v5.4s, v1.8h


scvtf v2.4s, v2.4s // int32x4_t -> float32x4_t
scvtf v3.4s, v3.4s
scvtf v4.4s, v4.4s
scvtf v5.4s, v5.4s


fmul v2.4s, v2.4s, v6.4s // v6.4s: float32x4_t 量化scale參數(shù)
fmul v3.4s, v3.4s, v6.4s 
fmul v4.4s, v4.4s, v6.4s 
fmul v5.4s, v5.4s, v6.4s
...

? 此處有同學(xué)可能會質(zhì)疑這么麻煩還有必要開發(fā)Int8量化的乘法算子嗎？具體原因可以參考之前關(guān)于開發(fā)Pooling量化算子的ATA文章，開頭有說明原因。 ?

?

?Segment fault出現(xiàn)的可能原因總結(jié)

在這里總結(jié)目前我遇到過的程序crash情況，后續(xù)也會在此添加更多的bug。

數(shù)據(jù)加載、存儲時，地址寄存器使用錯誤

函數(shù)參數(shù)加載地址時是否使用了錯誤的寄存器；

寫代碼過程中，是否給存儲地址的寄存器賦值了，導(dǎo)致寄存器的內(nèi)容改變；

循環(huán)加載、存儲數(shù)據(jù)時，原地址累加是否導(dǎo)致了越界；

寄存器開頭和結(jié)尾是否相應(yīng)地pushpop(stpldp)

通用寄存器的加減出錯，大多由于賦值錯誤或函數(shù)加載錯誤而間接導(dǎo)致

通用寄存器的內(nèi)容是否符合預(yù)期，可使用Printf的辦法驗(yàn)證

ARM64和ARM32中用于自動加載函數(shù)參數(shù)的寄存器個數(shù)分別是8個、4個

ARM64中通用寄存器賦值只能用32位，即w0,w1...根據(jù)需要決定是否使用uxtw擴(kuò)展到相應(yīng)的x0,x1...

函數(shù)參數(shù)類型聲明錯誤，導(dǎo)致加載錯誤

非整型函數(shù)參數(shù)一律用指針傳遞

整型常數(shù)參數(shù)盡量使用ssize_t, size_t

是否設(shè)置了循環(huán)退出條件，比如用于計(jì)數(shù)寄存器是否每次減1，循環(huán)退出條件是否能滿足

有一些寄存器是否忘記push就直接使用了，參考1.1節(jié)中的圖查詢哪些寄存器需要用完恢復(fù)

? 04ARM匯編的加速效果 ?

拿ConvolutionDepthwise的Int8量化算子舉例說明，C++版本的算子實(shí)現(xiàn)和ARM匯編版本的性能差距。測試模型中含有超過20個ConvolutionDepthwise算子。測試機(jī)我選擇了高端機(jī)華為Mate40 Pro和中端機(jī)華為P30 Pro，并使用ARM V8.2平臺的相關(guān)指令編寫匯編算子。測試結(jié)果中顯示的時間是該模型中所有ConvolutionDepthwise算子的耗時總和，顯然在ARM V8.2 64位平臺上，匯編算子的性能提高了約4.7倍。

?	C++版本	ARM V8.2 匯編
華為Mate40 Pro	11.28 ms	1.98 ms
華為P30 Pro	12.83 ms	2.22 ms

05團(tuán)隊(duì)介紹 ?

大淘寶技術(shù)Meta Team，負(fù)責(zé)面向消費(fèi)場景的3D/XR基礎(chǔ)技術(shù)建設(shè)和創(chuàng)新應(yīng)用探索，通過技術(shù)和應(yīng)用創(chuàng)新找到以手機(jī)及XR 新設(shè)備為載體的消費(fèi)購物3D/XR新體驗(yàn)。團(tuán)隊(duì)在端智能、商品三維重建、3D引擎、XR引擎等方面有深厚的技術(shù)積累。先后發(fā)布端側(cè)推理引擎MNN，端側(cè)實(shí)時視覺算法庫PixelAI，商品三維重建工具Object Drawer等技術(shù)。團(tuán)隊(duì)在OSDI、MLSys、CVPR、ICCV、NeurIPS、TPAMI等頂級學(xué)術(shù)會議和期刊上發(fā)表多篇論文。

　　審核編輯：湯梓紅