在LLVM程序中，functions, calls 和 invokes 可以带有一个可选的调用约定来指明调用方式。每一对caller/callee（调用者/被调用者）的调用约定必须相匹配，不然这个程序的行为是未定义的。
以下的是目前LLVM支持的调用约定形式，并且在未来可能会加入更多：
“ccc” – The C calling convention
这个调用约定（在没有标识其他调用约定时，为默认调用约定）匹配其目标到C调用约定。这个调用约定支持变长参数函数调用并可容忍函数的声明和实现之间存在某些不匹配的地方（像正常的
C一样）
“fastcc”- The fast calling convention
这个调用约定企图使调用尽可能的快速（如，通过寄存器传递参数）。这个调用约定允许目标使用任何技巧来为其产生快速的代码，不要求符合外部指定的ABI (Application Binary Interface). 尾部调用只能在 the GHC or the HiPE convention 被使用的时候优化。这种调用约定不支持变长参数切要求所有被调用者的原型与函数定义的原型相匹配。
“coldcc” – The cold calling convention
这种调用约定企图使调用者内的代码在假定这个调用不会被经常执行的情况下尽可能的有效率。像这种情况，这些调用通常会保护所有寄存器，因此这个调用不会破坏任何调用者内的生存范围（live ranges）。这种调用约定不支持变长参数切要求所有被调用者的原型与函数定义的原型相匹配。更进一步的，内联器（inliner）不会考虑把这种函数进行内联。
“cc 10” – GHC convention
这种调用约定被明确的实现来用于 Glasgow Haskell Compiler (GHC)。它传递所有东西到寄存器中，并通过禁止被调用者保存寄存器来实现这种极端的方式。这种调用约定不应该轻易地使用除非像在实现函数式编程语言时，一个可选的the register pinning性能技术经常被使用的情况下。在目前只有X86支持这种约定切它有以下限制：
- 在X86-32下只支持长度大于4bit的类型的形参，不支持浮点型；
- 在X86-64下只支持长度大于10bit的类型形参且只支持 （6 floating point parameters）
这种调用约定支持 tail call optimization但要求调用者和被调用者都使用这种调用约定。
“cc 11” – The HiPE calling convention
这种调用约定被明确实现来用于High-Performance Erlang (HiPE) compiler，the Ericsson’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. See Stack maps and patch points in LLVM.
“preserve_mostcc” – The PreserveMost calling 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-savedregister）数量方面要小很多（@note —因为coldcc需要在每一个函数内部保存所有寄存器导致了很多不必要的操作），但它们被使用于不同类型的函数调用。“coldcc”是用于那些很少被执行的函数调用，然而“preserve_mostcc”函数调用主要部分在于hot path且肯定被执行多次。（whereas preserve_mostcc function 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” – The PreserveAll calling 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运行期的一个未来版本，在目前被认为是实验性的.
“cxx_fast_tlscc” – The CXX_FAST_TLS calling convention for access functions
Clang生成一个访问函数来访问C++风格的TLS。访问函数通常具有入口块，出口块和第一次运行的初始化块。进入和退出块可以访问一些TLS IR变量，每个访问将降低到特定于平台的序列。
该调用约定旨在通过保留尽可能多的寄存器来最小化调用者的开销（所有在快速路径上保持的寄存器，由进入和退出块组成）。
此调用约定的行为与关于如何传递参数和返回值的C调用约定相同，但它使用一组不同的调用者/被调用者保存的寄存器。
鉴于每个平台都有自己的降序，因此它自己的保留寄存器集，我们不能使用现有的PreserveMost。
- 在X86-64上，被调用者保留所有通用寄存器，RDI和RAX除外。
“swiftcc” – This calling convention is used for Swift language.
- 在X86-64上，RCX和R8可用于其他整数返回，XMM2和XMM3可用于其他FP/向量返回。
- 在iOS平台上，我们使用AAPCS-VFP调用约定。“cc ” – Numbered convention
任何调用约定肯能被一个数字标识，来允许作为一个与特定目标相关的调用约定。与特定目标相关的调用约定开始于数字64。
如果有需要，更多得调用约定可能被增加/定义，从而支持Pascal调用约定或者其他任何知名的依赖于目标的调用约定。