JIT Compiler编译器及指令集

JIT Compiler编译器及指令集

 LLVM一些编程语法语义特性

High Level Structure

Module Structure

LLVM 程序由Module's组成，每个 's 是输入程序的一个翻译单元。每个模块由函数，全局变量和符号表条目组成。模块可与 LLVM 链接器组合在一起，后者合并函数（全局变量）定义，解析前向声明，合并符号表条目。这是“hello world”模块的示例：

; Declare the string constant as a global constant.

@.str=private unnamed_addr constant [13 x i8] c"hello world\0A\00"

; External declaration of the puts function

declare i32 @puts(i8* nocapture) nounwind

; Definition of main function

define i32 @main() {   ; i32()*

  ; Convert [13 x i8]* to i8*...

  %cast210=getelementptr [13 x i8]，[13 x i8]* @.str，i64 0，i64 0

  ; Call puts function to write out the string to stdout.

  call i32 @puts(i8* %cast210)

  ret i32 0

}

; Named metadata

!0=!{i32 42，null，!"string"}

!foo=!{!0}

这个示例是由全局变量命名为“ .str”，在一个外部声明“ puts”函数，函数定义为“main”，命名为元数据“ foo”。

通常，模块由全局值列表组成（函数和全局变量都是全局值）。全局值由指向内存位置的指针（指向字符数组的指针和指向函数的指针）表示。

命名元数据

命名元数据是元数据的集合。元数据节点（不是元数据字符串）是命名元数据的唯一有效算子。

1. 命名元数据表示为带有元数据前缀的字符串。元数据名称的规则与标识符相同，不允许引用名称。"\xx"类型转义仍然有效，允许任何字符成为名称的一部分。

句法：

; Some unnamed metadata nodes，which are referenced by the named metadata.

!0=!{!"zero"}

!1=!{!"one"}

!2=!{!"two"}

; A named metadata.

!name=!{!0，!1，!2}

参数属性

函数类型的返回类型和每个参数，可能有一组与之关联的参数属性。参数属性用于传达有关函数结果，或参数的附加信息。参数属性被认为是函数的一部分，不是函数类型，具有不同参数属性的函数，可具有相同的函数类型。

参数属性是遵循指定类型的简单关键字。如果需要多个参数属性，空格分隔。例如：

declare i32 @printf(i8* noalias nocapture，...)

declare i32 @atoi(i8 zeroext)

declare signext i8 @returns_signed_char()

前缀数据

前缀数据是与函数关联的数据，代码生成器将在函数入口点前面立即发出数据。允许前端将特定语言的运行时元数据与特定函数相关联，通过函数指针可用，允许调用函数指针。

要访问给定函数的数据，程序可将函数指针位转换为指向常量类型的指针，取消引用索引 -1。IR 符号刚好越过前缀数据的末尾。例如，一个用单i32个，注释的函数为例。

define void @f() prefix i32 123 { ... }

前缀数据可引用

%0=bitcast void* () @f to i32*

%a=getelementptr inbounds i32，i32* %0，i32 -1

%b=load i32，i32* %a

define void @f() prologue i8 144 { ... }

序言数据

prologue属性允许在函数体前面，插入任意代码（编码为字节）。用于启用功能热修补和检测。

为了维护普通函数调用的语义，序言数据必须具有特定的格式。具体，必须以一个字节序列开始，这些字节序列解码为一系列机器指令，对模块的目标有效，这些指令将控制转移到序言数据后的点，不执行任何可见的操作。允许内联和通道推理函数定义的语义，无需推理序言数据。使得序言数据的格式高度依赖于目标。

x86 架构的有效序言数据的一个简单示例，对指令进行编码：i8 144nop

define void @f() prologue i8 144 { ... }

通常可通过编码，跳过元数据的相对分支指令，形成序言数据，如x86_64架构的有效序言数据示例，前两个字节编码：jmp .+10

%0=type <{ i8，i8，i8* }>

define void @f() prologue %0 <{ i8 235，i8 8，i8* @md}> { ... }

; Target-independent attributes:

attributes #0={ alwaysinline alignstack=4 }

; Target-dependent attributes:

attributes #1={ "no-sse" }

; Function @f has attributes: alwaysinline，alignstack=4，and "no-sse".

define void @f() #0 #1 { ... }

属性组

属性组是由 IR 内的对象引用的属性组。对于保持.ll文件可读很重要，许多函数将使用相同的属性集。在.ll文件对应于单个.c文件的退化情况下，单个属性组将捕获用于构建文件的重要命令行标志。

属性组是模块级对象。要使用属性组，对象引用属性组的 ID（如#37）。一个对象可能引用多个属性组。在这种情况下，不同组的属性将合并。

下面是一个函数的属性组示例，函数始终内联，堆栈对齐为 4，不应使用 SSE 指令：

define void @f() noinline { ... }

define void @f() alwaysinline { ... }

define void @f() alwaysinline optsize { ... }

define void @f() optsize { ... }

去优化算子包

去优化算子包的特点是"deopt" 算子包标签。这些算子包代表了所连接的调用站点的替代“安全”延续，可由合适的运行时使用，取消优化指定调用站点的编译帧。最多可有一个"deopt"算子束，附加到调用站点。去优化的确切细节超出了语言参考的范围，通常涉及将编译帧重写为一组解释帧。

从编译器的角度，去优化算子包，所连接的调用点，至少连接到readonly。通读了所有指针类型的算子（即使没有以其它方式转义）和整个可见堆。去优化算子包不捕获算子，除非在去优化期间，在这种情况下控制，不会返回到编译帧。

内联器知道如何通过具有去优化算子包的调用进行内联。就像通过普通调用站点内联涉及组合正常和异常延续一样，通过具有去优化算子包的调用站点，内联需要适当地组合“安全”去优化延续。内联程序通过将父级的去优化延续，添加到内联正文中的每个去优化延续前面，做到这一点。例如内联@f到@g在下面的示例中

define void @f() {

  call void @x()  ;; no deopt state

  call void @y() ["deopt"(i32 10)]

  call void @y() ["deopt"(i32 10)，"unknown"(i8* null)]

  ret void

}

define void @g() {

  call void @f() ["deopt"(i32 20)]

  ret void

}

导致

define void @g() {

  call void @x()  ;; still no deopt state

  call void @y() ["deopt"(i32 20，i32 10)]

  call void @y() ["deopt"(i32 20，i32 10)，"unknown"(i8* null)]

  ret void

}

在每个需要 a 的规范上<abi>:<pref>，指定 <pref>对齐方式是可选的。如果省略，前面的省略，<pref>等于<abi>。

在为给定目标构建数据布局时，LLVM从一组默认规范开始，然后（可能）被datalayout关键字中的规范覆盖。此列表中给出了默认规格：

• E - big endian
• p:64:64:64 - 64-bit pointers with 64-bit alignment.
• p[n]:64:64:64 - Other address spaces are assumed to be the same as the default address space.
• S0 - natural stack alignment is unspecified
• i1:8:8 - i1 is 8-bit (byte) aligned
• i8:8:8 - i8 is 8-bit (byte) aligned
• i16:16:16 - i16 is 16-bit aligned
• i32:32:32 - i32 is 32-bit aligned
• i64:32:64 - i64 has ABI alignment of 32-bits but preferred alignment of 64-bits
• f16:16:16 - half is 16-bit aligned
• f32:32:32 - float is 32-bit aligned
• f64:64:64 - double is 64-bit aligned
• f128:128:128 - quad is 128-bit aligned
• v64:64:64 - 64-bit vector is 64-bit aligned
• v128:128:128 - 128-bit vector is 128-bit aligned
• a:0:64 - aggregates are 64-bit aligned

用列order指令

用列指令，对每个用列的内存顺序进行编码，允许重重排序。<order-indexes>是分配给引用值的使用的索引的逗号分隔列表。引用值的用列，实时按这些索引排序。

用列指令，可能出现在函数作用域，或全局作用域。不是指令，对 IR 的语义没有影响。当处于函数作用域时，必须出现在最终基本块的终止符后。

如果基本块的地址，通过blockaddress()表达式获取，uselistorder_bb从函数范围外重新排序用列。

uselistorder <ty> <value>，{ <order-indexes> }

uselistorder_bb @function，%block { <order-indexes> }

define void @foo(i32 %arg1，i32 %arg2) {

entry:

  ; ... instructions ...

bb:

  ; ... instructions ...

  ; At function scope.

  uselistorder i32 %arg1，{ 1，0，2 }

  uselistorder label %bb，{ 1，0 }

}

; At global scope.

uselistorder i32* @global，{ 1，2，0 }

uselistorder i32 7，{ 1，0 }

uselistorder i32 (i32) @bar，{ 1，0 }

uselistorder_bb @foo，%bb，{ 5，1，3，2，0，4 }

函数类型

函数类型可被认为是一个函数签名。由一个返回类型和一个形参类型列表组成。函数类型的返回类型是 void 类型，或第一类类型——标签和元数据类型除外。

<returntype> (<parameter list>)

<类型>  *

% T1 = type  {  <类型 列表>  }      ;  已知的 正常 结构体 类型

% T2 = type  < {  <类型 列表>  } >    ;  已知的 压缩 结构 类型

@X=global i32 17

@Y=global i32 42

@Z=global [2 x i32*] [i32* @X，i32* @Y]

  %A=add %X，undef

  %B=sub %X，undef

  %C=xor %X，undef

Safe:

  %A=undef

  %B=undef

  %C=undef

%A=or %X，undef

  %B=and %X，undef

Safe:

  %A=-1

  %B=0

Safe:

  %A=%X  ;; By choosing undef as 0

  %B=%X  ;; By choosing undef as -1

Unsafe:

  %A=undef

  %B=undef

  %A=select undef，%X，%Y

  %B=select undef，42，%Y

  %C=select %X，%Y，undef

Safe:

  %A=%X     (or %Y)

  %B=42     (or %Y)

  %C=%Y

Unsafe:

  %A=undef

  %B=undef

  %A=xor undef，undef 

  %B=undef 

  %C=xor %B，%B 

  %D=undef 

  %E=icmp slt %D，4 

  %F=icmp gte %D，4 

Safe: 

  %A=undef 

  %B=undef 

  %C=undef 

  %D=undef 

  %E=undef 

  %F=undef

  %A=fdiv undef，%X

  %B=fdiv %X，undef

Safe:

  %A=undef

b: unreachable

a:  store undef -> %X

b:  store %X -> undef

Safe:

a: <deleted>

b: unreachable

entry:

  %poison=sub nuw i32 0，1           ; Results in a poison value.

  %still_poison=and i32 %poison，0   ; 0，but also poison.

  %poison_yet_again=getelementptr i32，i32* @h，i32 %still_poison

  store i32 0，i32* %poison_yet_again  ; memory at @h[0] is poisoned

  store i32 %poison，i32* @g           ; Poison value stored to memory.

  %poison2=load i32，i32* @g         ; Poison value loaded back from memory.

  store volatile i32 %poison，i32* @g  ; External observation; undefined behavior.

  %narrowaddr=bitcast i32* @g to i16*

  %wideaddr=bitcast i32* @g to i64*

  %poison3=load i16，i16* %narrowaddr ; Returns a poison value.

  %poison4=load i64，i64* %wideaddr  ; Returns a poison value.

  %cmp=icmp slt i32 %poison，0       ; Returns a poison value.

  br i1 %cmp，label %true，label %end  ; Branch to either destination.

true:

  store volatile i32 0，i32* @g        ; This is control-dependent on %cmp，so

                                       ; it has undefined behavior.

  br label %end

end:

  %p=phi i32 [0，%entry]，[1，%true]

                                       ; Both edges into this PHI are

                                       ; control-dependent on %cmp，so this

                                       ; always results in a poison value.

  store volatile i32 0，i32* @g        ; This would depend on the store in %true

                                       ; if %cmp is true，or the store in %entry

                                       ; otherwise，so this is undefined behavior.

  br i1 %cmp，label %second_true，label %second_end

                                       ; The same branch again，but this time the

                                       ; true block doesn't have side effects.

second_true:

  ; No side effects!

  ret void

second_end:

  store volatile i32 0，i32* @g        ; This time，the instruction always depends

                                       ; on the store in %end. Also，it is

                                       ; control-equivalent to %end，so this is

                                       ; well-defined (ignoring earlier undefined

                                       ; behavior in this example).

参考链接：

https://releases.llvm.org/6.0.0/docs/LangRef.html#module-structure

标签：undef,函数,i32,void,JIT,编译器,64,类型,Compiler
来源： https://www.cnblogs.com/wujianming-110117/p/15502018.html