LLVMfunctions,callsandinvokes可以帶有一個可選的調用約定來指明調用方式。每一對 caller/callee（調用者/被調用者）的調用約定必須相匹配，不然這個程序的行為是未定義的。下面的是LLVM支持的調用約定形式，并且在未來可能會加入更多：

“ccc” - The C calling convention

這個調用約定（在沒有標識其他調用約定時，為默認調用約定）匹配其目標到C調用約定。這個調用約定支持變長參數函數調用并可容忍函數的聲明和實現之間存在某些不匹配的地方（像正常的 C一樣）

“fastcc” - The fast calling convention

這個調用約定企圖使調用盡可能的快速（如，通過寄存器傳遞參數）。這個調用約定允許目標使用任何技巧來為其產生快速的代碼，不要求符合外部指定的ABI(application Binary Interface). 尾部調用只能在theGHC or the HipE convention 被使用的時候優化。這種調用約定不支持變長參數切要求所有被調用者的原型與函數定義的原型相匹配。

“coldcc” - The cold calling convention

這種調用約定企圖使調用者內的代碼在假定這個調用不會被經常執行的情況下盡可能的有效率。像這種情況，這些調用通常會保護所有寄存器，因此這個調用不會破壞任何調用者內的生存范圍（live ranges）。這種調用約定不支持變長參數切要求所有被調用者的原型與函數定義的原型相匹配。更進一步的，內聯器（inliner）不會考慮把這種函數進行內聯。

“cc10” - GHC convention

這種調用約定被明確的實現來用于Glasgow Haskell Compiler (GHC)。它傳遞所有東西到寄存器中，并通過禁止被調用者保存寄存器來實現這種極端的方式。這種調用約定不應該輕易地使用除非像在實現函數式編程語言時，一個可選的the register pinning性能技術經常被使用的情況下。在目前只有X86支持這種約定切它有以下限制：

~ 在X86-32下只支持長度大于4bit的類型的形參。不支持浮點型。

~ 在X86-64下只支持長度大于10bit的類型形參且只支持 （6 floating point parameters？）

這種調用約定支持tail call optimization但要求調用者和被調用者都使用這種調用約定。

“cc11” - The HiPE calling convention

這種調用約定被明確實現來用于High-Performance Erlang (HiPE)compiler，theEriCSSon’s Open Source Erlang/OTP system的本地編譯器。它比普通的C調用約定使用了更多寄存器來用于實參的傳遞和定義非調用者保存寄存器（no callee-saved registers）。這個調用約定正確地支持尾部調用優化但要求調用者和被調用者都是用這個調用約定。它使用一個與GHC’s 約定相似的register pinning機制來保持被壓在指定硬件寄存器上的運行時組件的頻繁訪問。在目前，只有X86支持這種調用約定（包括32位和64位）。

“webkit_jscc” - WebKit’s javaScript calling convention

這種調用約定被實現用于WebKit FTL JIT。它從右到左向stack傳遞實參（像cdcel 調用約定一樣），并且返回一個值到平臺所定義的返回寄存器中。

anyregcc” - Dynamic calling convention for code patching

這種特殊的調用約定支持修補一段任意的代碼序列來取代一個調用地點（call site）。這種調用約定強制調用的實參到寄存器中但允許他們被動態分配。這種調用約定只能被llvm中的調用使用。這種調用約定是實驗性的。patchpoint because only this intrinsic records the location of its arguments in a side table.SeeStack maps and patch points in LLVM.“

“PReserve_mostcc” - ThePreserveMostcalling convention

這種調用約定企圖使調用者中的代碼盡可能地少受干擾。這種調用約定在如何傳遞實參和返回值上與C調用約定完全一致，但“preserve_mostcc” 使用不同的調用者保存寄存器和非調用者保存寄存器（caller/callee-saved register）集。這樣可以減輕在調用開始和結束需要保存和恢復大量寄存器集的負擔。如果實參傳遞到非調用者保存寄存器（callee-saved registers），那么他們會被被調用者保護起來。不能使用從非調用者保存寄存器（callee-saved registers）返回的值。

~ 在X86-64中被調用者保護所有普通目的寄存器，除了R11。R11可能被用作scratch register。浮點寄存器（XMMs/YMMs）不會被保護且需要被調用者保護。

這種調用約定背后的想法支持調用擁有一個 hot path 和一個 cold path的運行期函數。hot path通常是不需要太多寄存器的小代碼塊。cold path可能需要調用另一個函數并且僅僅需要保護那些未被調用者保存的調用者保存寄存器（caller-saved registers）。“preserve_mostcc” 調用約定在調用者保存寄存器和非調用者保存寄存器（caller/callee-saved register）數量方面要小很多（@note -- 因為coldcc需要在每一個函數內部保存所有寄存器導致了很多不必要的操作），但它們被使用于不同類型的函數調用。“coldcc”是用于那些很少被執行的函數調用，然而“preserve_mostcc”函數調用主要部分在于hot path且肯定被執行多次。（whereaspreserve_mostccfunction calls are intended to be on the hot path and definitely executed a lot.）此外，“preserve_mostcc”不能防止內聯器（linker）內聯這個函數調用。

這種調用約定將會被使用到Objective-C運行期的一個未來版本，因此該調用約定在目前仍然被認為是實驗性的。計時這個約定已經被創建來優化確定的Objective-C運行期的運行期調用，它并不受限于Objective-C的運行期，在未來可能會被使用于其他運行期。當前的實現僅支持X86-64，但在未來會試吃更多得體系架構。

“preserve_allcc” - ThePreserveAllcalling convention

這種調用約定企圖使調用者中的代碼盡可能地少受干擾。這種調用約定在如何傳遞實參和返回值上與C調用約定完全一致，但“preserve_mostcc” 使用不同的調用者保存寄存器和非調用者保存寄存器（caller/callee-saved register）集。這樣可以減輕在調用開始和結束需要保存和恢復大量寄存器集的負擔。如果實參傳遞到非調用者保存寄存器（callee-saved registers），那么他們會被被調用者保護起來。不能使用從非調用者保存寄存器（callee-saved registers）返回的值。

~ 在X86-64中被調用者保護所有普通目的寄存器，除了R11。R11可能被用作scratch register。浮點寄存器（XMMs/YMMs）不會被保護且需要被調用者保護。

這種調用約定背后的想法支持不需要調用其它函數的運行期函數。

這種調用約定，類似于“preserve_mostcc”調用約定，會被使用于Objective-C運行期的一個未來版本，在目前被認為是實驗性的

“cc<n>” - Numbered convention

任何調用約定肯能被一個數字標識，來允許作為一個與特定目標相關的調用約定。與特定目標相關的調用約定開始于數字64。

更多得調用約定可能被增加/定義在需要的基礎上，從而支持Pascal調用約定或者其他任何知名的依賴于目標的調用約定。