llvm之IR手册翻译（3）

原网址是：http://llvm.org/docs/LangRef.html#abstract；
下面这些是我自己的翻译，肯定有很多不恰当的地方，做这些只是希望自己以后翻阅更加方便，如果能对大家有所帮助那是极好的！

---

appending(附加)
“appending”链接类型仅被应用到指向数组类型的指针的全局变量。当两个全局变量是“appending”链接类型时它们连在一起的，这两个全局数组附加在一起。这是LLVM，类型安全，相当于其系统链接附加的“部分”具有相同的名称当.o文件链接的。
extern_weak
这种链接类型遵循ELF目标文件模型：符号是弱类型，直到联系，如果没有联系，该符号变为null，而不是作为一个未定义的引用。
linkonce_odr, weak_odr
某些语言允许不同的全局值被合并，如两个函数具有不同的语义。其他语言，如C++，确保只有相同的全局值可以合并（“一个定义规则” - “ODR”）。这些语言可以使用linkonce_odr和weak_odr链接类型指示该全局值将只与等效全局值合并。否则这些链接类型是非ODR版本。
external
如果上述标识符的使用，全局外部是可见的，这意味着它参与链接，并可以用于解决外部符号引用。
对于一个函数只能声明为external或者extern_weak链接类型。
调用约定
LLVM的函数，call和invoke都可以对调用指定一个可选的调用约定。任何一对动态调用调用和被调用，其调用约定必须匹配，或者程序的调用约定是不确定的。以下调用约定被LLVM支持，更多的可能在未来加入：
“ccc” - C调用约定
该调用约定（默认）与目标C调用约定相匹配。该调用约定支持可变参数的函数调用和容忍函数声明原型和实现声明的不匹配（如普通的C）。
“fastcc” - 快速调用约定
该调用约定试图尽可能快地（例如，寄存器传递参数）调用。这种调用约定允许目标使用任何技巧，它以产生快速的代码为目标，而不必遵循外部指定的ABI（应用程序二进制接口）。使用GHC或HIPE约定用于Tail Call（就是指一个函数返回的值，为另一个函数的返回值）优化。该调用约定不支持可变参数，并要求所有调用的函数定义的原型完全匹配函数声明原型。
“coldcc” - 冷调用约定
该调用约定试图使主叫代码尽可能高效的假设调用不经常执行。因此，这些调用往往保护所有的寄存器，以至于调用不会破坏任何主叫方的生成序列。该调用约定不支持可变参数，并要求所有被调用者的原型函数和定义的原型完全匹配。此外，内联并没有考虑这样的内联函数调用约定。
“cc10” - GHC约定
该调用约定已经实现专门为Glasgow Haskell的编译器（GHC）使用。所有数据传递都在寄存器中，极端到禁用被叫方保存寄存器来实现这一目标。该调用约定一般不用，但仅用于特殊情况下，如代替实现函数式编程语言时经常使用寄存器pinning性能的技术。目前只有X86支持该约定，它具有以下限制：
在X86-32只到4位的类型参数支持。没有浮点类型的支持。
在X86-64仅达10位类型参数和6个浮点参数支持。
该调用约定支持尾调用优化，但同时需要调用者和被调用者都在使用它。
“cc11” - HiPE调用约定
该调用约定已经实现专供高性能Erlang（HiPE）编译器使用，爱立信开源的Erlang/ OTP系统提供本机代码编译。它比普通的C调用约定使用更多的寄存器用于参数传递，并定义没有被调用方保存寄存器。调用约定适当支持尾调用优化，但需要无论是主叫方和被叫方使用该约定。它采用了寄存器pinning机制，类似于GHC的习惯，保持特定的硬件寄存器到经常访问的运行时组件。目前只有X86支持该约定（32位和64位）。
“webkit_jscc” - WebKit’s JavaScript调用约定
该调用约定实施为了WebKit FTL JIT。它在堆栈中从右到左传递参数（如同cdecl），并且返回值在常用返回寄存器中。
“anyregcc” - 代码补丁动态调用约定
这是支持修补任意代码序列代替调用点的特殊的约定。该公约强制从寄存器调用参数，但使它们能够动态分配。目前只能调用llvm.experimental.patchpoint，因为只有这种内在的记录记录了参数在表的位置。在LLVM中看堆栈图和补丁点。
“preserve_mostcc” - 的PreserveMost调用约定
该调用约定试图使调用者的代码越非侵入越好。该约定与C调用约定如何传递参数和返回值都相同，但它使用一组不同的调用者/被调用者保存寄存器。这减轻了保存和恢复大量寄存器调用之前和之后调用者的负担。如果参数传递在被调用者保存寄存器，它会在整个调用过程中被保护。这并不适用于调用者保存寄存器的返回值。
在X86-64被调用者保留所有通用寄存器，除R11，R11可以用作暂存寄存器。浮点寄存器（XMMs/ YMMs）不保留并且需要由调用者保存。
这个约定背后的想法是支持调用函数运行时有一个热部分和冷通部分。热部分通常是一小片，不使用多个寄存器的代码。冷部分可能需要调用另一个函数，因此只需要保留调用者保存寄存器，其尚未被调用者保存。该PreserveMost调用约定是非常相似的主叫/被叫方保存的寄存器方面寒冷的调用约定，但它们用于不同类型的函数调用。 coldcc为很少执行的，而preserve_mostcc函数调用旨在是热路径上，肯定执行很多功能调用。此外preserve_mostcc并不妨碍内联的内联函数调用。
这个约定背后的想法是支持调用函数运行时有一个热通路和冷通路。热通路通常是一小部分，不使用多个寄存器的代码。冷通路可能需要调出到另一个函数，因此，只需要保留被调用者保存的调用者保存寄存器。“PreserveMost”调用约定在调用者/被调用者保寄存器方面与“coldcc”调用约定非常相似的，但它们用于不同类型的函数调用。coldcc为很少执行的函数，而preserve_mostcc旨在调用函数是热通路上并且肯定执行很多次。此外preserve_mostcc并不妨碍内联的内联函数调用。
该调用约定将要被ObjectiveC运行时库的后续版本使用，因此应该仍然被认为当前是实验性的。虽然这种约定是为了优化某些运行时间当调用ObjectiveC运行时库，它并不限于此运行时库和在将来可能被其它运行时库所使用。当前的实现仅支持X86-64，但其未来将支持更多的体系结构
“preserve_allcc” - PreserveAll调用约定
该调用约定试图使代码在调用者比PreserveMost调用约定更少侵入。该调用约定在如何参数和返回值等同于C调用约定，但它使用一组不同的调用者/被调用者保存寄存器。这将去除保存和恢复大量寄存器调用函数之前和之后的负担。如果参数传递是被调用者保存寄存器，它将被被调用者在整个调用阶段保留。这并不适用于返回值在被调用者保存寄存器中。
在X86-64被调用者保留所有通用寄存器，除R11，R11可以用作暂存寄存器。此外，它也保留了所有的浮点寄存器（XMMS / YMMs）。
这个约定背后的想法是支持调用运行时库函数时不需要调用任何其他函数。
该调用约定，如同PreserveMost调用约定，将要被ObjectiveC运行时库的未来版本使用，应被认为处在实验性阶段。
“cc” - 编号约定
任何调用约定可以由数被指定，从而允许使用特定目标调用约定。针对具体的调用约定开始为64。
更多的调用约定可以根据需要添加/定义，以支持Pascal约定或任何其他通用独立目标的约定。
可见形式
所有的全局变量和函数具有下列可见性形式之一：
“default” - 默认形式
当目标使用ELF对象文件格式，默认可见性意味着声明对其它模块可见，并在共享库，意味着声明实体可能会被改写。当在Darwin(由苹果电脑于2000年所释出的一个开放原始码操作系统)，默认可见性意味着声明对其它模块可见。默认可见性在语言上对应于“external linkage”。
“hidden” - 隐藏形式
两个声明的对象是隐藏能见性指它们共享相同的对象。一般的，隐藏的可见性表明该符号将不被置于动态符号表，所以没有其它模块（可执行或共享库）可以直接引用它。
“protected” - 保护样式
在ELF上，受保护的可见性表明该符号将被放置在动态符号表，但定义模块的引用将结合到本地符号。即，符号不能被另一个模块所覆盖。
“internal”或“private”链接类型的符号必须有默认的可见性。
DLL存储类
所有的全局变量，函数和别名可以有以下的DLL存储类之一：
dllimport
“dllimport”使编译器引用函数或变量通过全局指针指向一个由DLL导出符号的指针。在Microsoft Windows目标，指针名是由组合imp和函数或变量名组成。
dllexport
“dllexport”使编译器提供一个全局指针指向在DLL中的指针，以便它可以被dllimport的属性来引用。在Microsoft Windows，指针名是由组合imp和函数或变量名组成。由于此存储类存在定义一个DLL接口，编译器，汇编器和链接器知道它是外部引用，必须避免删除符号。
线程本地存储模型
变量可以定义为thread_local，这意味着它不会被线程共享（每个线程将具有变量的分隔副本）。不是所有的目标都支持线程局部变量。可选的，一个TLS模型可以指定：
localdynamic
对于变量只是当前共享库中使用。
initialexec
变量在模块中不会被动态加载。
localexec
在可执行文件中定义变量并且只在其内使用。
如果没有明确的模型，使用“general dynamic”。
该模式对应ELF TLS模型；不同环境下的不同模式更多信息可以在 “ELF Handling For Thread-Local Storage”中看到。目标可以选择不同的TLS模式如果不支持指定的模式，或者如果有更好的选择模型，可以制成。
模型也可以用在一个别名中指定，但随后只控制别名如何访问。它不会有在其他别名的任何影响。
对于不支持链接的ELF TLS模型平台上，-femulated-TLS标志可用于生成GCC兼容仿真TLS代码。
结构类型
LLVM IR允许你同时指定“identified”和“literal”的结构类型。“literal”类型是独特的结构，但“identified”类型不是独特的。一个不透明的结构型式，也可用于前向声明一个类型，尚不可用。
“identified”结构规范的一个例子是：
%mytype = type { %mytype*, i32 }
在此之前的LLVM3.0发布，“identified”类型是独特结构。近LLVM的版本，只有“literal”类型是独特结构。

---

未完待续