在設計一門語言與其他語言交互的API與ABI（Application Binary Interface，二進制接口）時，調用協議和內存對齊是兩個無從回避的問題。

本文將討論如何在LLVM上生成正確的內存對齊和調用協議的代碼。

在這里為了方便和標準起見，假定應用LLVM的語言的Extending和Embedding的對象都是C。

調用協議

先來討論調用協議。調用協議用于保證調用方和被調用方在二進制/匯編一級上是相容的。合適的調用協議可以幫助構造出以下代碼：

// Callee Signature of LLVM code
void __cdecl foo( int a, float b, float4 c);

// C caller
typedef void (__cdecl* fn_ptr)(int, float, float4)
fn_ptr p = static_cast<fn_ptr>( get_jit_function("foo") );
p(1, 1.0, vec);

一般來說調用協議包括參數傳遞和返回值傳遞和堆棧平衡三個部分。在x86平臺上的C/C++編譯器中常見的調用協議有cdecl, fastcall和stdcall。具體的協議內容請參見MSDN。

在C++中還有一類特殊的調用協議thiscall，用于調用對象的成員函數。但是這一類調用協議不同的平臺，不同的編譯器實現皆有不同，既無書面標準，也無事實標準，再加上virtual call等復雜的情況存在，并不適合用于做跨語言的調用。

對于x64平臺而言，在windows下和linux下分別有兩種調用協議。

先來看x86。由于x86在cdecl和fastcall上是有著跨平臺的標準的，因此LLVM對它的支持是比較完整的。程序只要在創建Function的時候指定Call Convention即可。

但是對于x64，LLVM的支持便不是那么完善。以windows為例，windows的x64調用協議要求以rcx，rdx，r8，r9寄存器傳遞前四個不大于64bit的參數，其余參數放在棧上。如果參數大于64bit，則要求傳遞它的指針。浮點使用xmm0-3來傳遞。但是對于LLVM而言，一旦參數大于64bit，它便會將整個對象而不是指針壓到棧上傳遞。因此在遇到x64時，需要小心處理API部分的調用協議。

在這里，我們需要將所有超過64bit的結構體處理成指針（或者拷貝后處理成指針）傳遞。

同時，LLVM提供了readonly和byval兩個參數屬性（Attribute）來確保參數的值語義。前者意味著傳入的指針所指向的值是不被修改的，（類似于T const*），而后者會對傳入的指針做一份內存拷貝，確保寫值不被傳遞出函數（類似于值拷貝）。這樣，LLVM生成的函數便可以MSVC生成的x64代碼正確調用了。

內存對齊

與移動平臺的體系結構相比，x86對內存對齊的條件算是相當寬松的了。大部分的指令對內存對齊基本上是沒有特殊要求的。只有一些SIMD的指令會對內存對齊有所限定，例如movaps。

為了方便后端生成SIMD代碼，LLVM提供了vector類型，例如vector<float, 1>。在代碼生成的時候，vector會編譯成最有可能的SIMD類型。因此在x86平臺上，vector<float, 1-4>都被處理成類似于__m128的類型，更長的vector則被拆分成多個__m128類型。

這實際上意味著，所有的vector都應該遵循16Bytes對齊的原則。

考慮到我們的需求，類似于struct{ float[3]; }這樣的結構，如果能表示為vector<float, 3>顯然適合一些數學運算，例如shuffle，逐元素的add，sub，mul，同時LLVM指令的選擇也更加靈活。但是顯然，這個結構體有兩個條件是不滿足的：16字節對齊和16字節的大小（movups和movaps都是一次取16字節）。這會造成邊界下讀寫的內存越界。因此非常可惜，這些數據必須表示為struct{ float ,float, float }。在讀取的時候，也會生成正確的指令：movss。

那么，對于一般的非對齊的vec4應用vector<float,4>行不行呢？

答案是，很困難。對于LLVM而言，他們在設計的時候就沒有過多的考慮vector在非對齊時候的應用。盡管load和store都能夠指定alignment以生成非對齊的內存操作（例如movups）并且確實會起效，但是由于代碼優化、臨時存取等特性的存在，導致一些非load和store的內存操作仍然是要求對齊的（例如生成了addaps xmm, [addr]）。此時仍然有可能為非對齊的數據生成了內存對齊的指令。

因此綜合權衡，SASL在API界面上使用了struct{float x,y,z,w;} 這樣的ABI來表示數據，在代碼生成時，會首先將struct的數據轉換成vector，然后再執行其它的操作，兼顧ABI與SIMD；同時對于Intrinsic，由于并不暴露給Host，所以它們仍然盡可能使用Vector，便于LLVM進行優化。