LLVM Instruction Selection 笔记

2024-05-06 00:36

本文主要是介绍LLVM Instruction Selection 笔记,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

Instruction Selection 所处阶段

注:上图来源于 Welcome to the back-end: The LLVM machine representation

可以看到 SelectionDAG 架在 LLVM IR 和 LLVM MIR 之间,在此之前 machine independent optimization 已经完成。之后基本上就进入了 machine dependent 的阶段。

SelectionDAG

众所周知编译的过程就是将一种 “语言” 转换为另外一种 “语言”,其中要保持程序语义的性质不变,中间会做一些“变换”。常规认知中的编译是将 “高级语言” 变换为 “机器语言”,中间会经历一些列的 lowering 的阶段,每一个 lowering 的阶段几乎都会伴随一个中间的抽象形式来方便做性质分析和优化变换。对于常规的 C++ 语言来将,大致会经历如下几个阶段,

不同的 “抽象” 用于不同的目的,例如 LLVM IR SSA 用来更好的做优化,AST 用来做 syntax 和 semantic 检查,而 SelectionDAG 主要是用来做 Instruction Selection 以及一些的简单的变换(或者说 scheduling)。中间可能会穿插一些其它的辅助数据结构,例如 CFG, CallGraph 以及 Dom Tree等等。我们以下面的 C 代码为例,看下各个抽象分别长什么样子。

long imul(long a, long b) {return a * b;
}
AST

clang test.c -Xclang -ast-dump

LLVM IR SSA

clang test.c -S -emit-llvm

LLVM IR CFG 

opt test.ll -passes='dot-cfg'

SelectionDAG

llc test.ll --view-dag-combine1-dags=1

llc test.ll --view-isel-dags=1

llc test.ll --view-sched-dags=1

The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the SDNode class. The primary payload of the SDNode is its operation code (Opcode) that indicates what operation the node performs and the operands to the operation. The various operation node types are described at the top of the include/llvm/CodeGen/ISDOpcodes.h file.  The LLVM Target-Independent Code Generator — LLVM 19.0.0git documentation

SelectionDAG 是以 basic block 为单位的,也就是说后续的 instruction selection 所能看到的范围也是 basic block 内部

源码
int fac(int num) {if (num == 1) return 1;return fac(num - 1) * num;
}
LLVM CFG

opt test.cpp.ll -passes='dot-cfg'

Selection DAG

llc test.cpp.ll --view-dag-combine1-dags=1

我们还是以下面的代码为例简单介绍其 SelectionDAG。

long imul(long a, long b) {return a * b;
}// LLVM IR
; Function Attrs: noinline nounwind optnone uwtable
define dso_local i64 @imul(i64 noundef %a, i64 noundef %b) #0 {
entry:%a.addr = alloca i64, align 8%b.addr = alloca i64, align 8store i64 %a, ptr %a.addr, align 8store i64 %b, ptr %b.addr, align 8%0 = load i64, ptr %a.addr, align 8%1 = load i64, ptr %b.addr, align 8%mul = mul nsw i64 %0, %1ret i64 %mul
}

Data flow dependencies: Simple edges with integer or floating point value type. Black Edges

Control flow dependencies: "chain" edges which are of type MVT::Other.

Chain edges provide an ordering between nodes that have side effects. Blue Edges

Glue Edges forbids breaking up instructions.

Convention:

  • Chain inputs are always operand #0

  • Chain results are always the last value produced by an operation

Entry & Root nodes

Entry node: A marker node with an Opcode of ISD::EntryToken.

Root node: Final side-effecting node in the token chain. The LLVM Target-Independent Code Generator — LLVM 19.0.0git documentation

下面的图有些复杂,这里分别介绍下

  • 下图中每个节点都实例化自SDNode class,像是加减乘除等,详细的见 `include/llvm/CodeGen/ISDOpcodes.h`
  • 每个 SDNode 有0个或者多个输入,边实例化自SDValue class
  • SDNode 产生的 value 的类型为 Machine Value Type(MTV) 例如,i1i8 分别表示 1bit 和 8bit 的整型
  • 可能有副作用的节点会强行要求顺序,也就是会在输入和输出强行安插一个 chain dependence。

These edges provide an ordering between nodes that have side effects (such as loads, stores, calls, returns, etc). All nodes that have side effects should take a token chain as input and produce a new one as output. By convention, token chain inputs are always operand #0, and chain results are always the last value produced by an operation. The LLVM Target-Independent Code Generator — LLVM 19.0.0git documentation

我们可以看到 `t2` 和 `t4` 的 SDNode 的 OpCode 是 `CopyFromReg`。它表示 %a%b 从外部来的值。

CopyFromReg - This node indicates that the input value is a virtual or physical register that is defined outside of the scope of this SelectionDAG.

FrameIndex<0> 和 FrameIndex<1> 用来表示栈上的一个对象,表示 %a.addr 和 %b.addr

A serializaable representation of a reference to a stack object or fixed stack object.

实线表示有实际的值流动表示 flow dependencies。蓝色虚线表示 chain dependency,在指令调度时要保持顺序,例如下图中的两条 load 指令不能调度到最后一条 store 指令前面。因为它们可能会有隐含的“依赖关系”,例如可能会 access 同一块儿内存。所以编译器会额外添加一条 chain 依赖,使用 `ch` 表示。

//===- X86ISelDAGToDAG.cpp - A DAG pattern matching inst selector for X86 -===//
#define DEBUG_TYPE "x86-isel"
#define PASS_NAME "X86 DAG->DAG Instruction Selection"
//===--------------------------------------------------------------------===//
/// ISel - X86-specific code to select X86 machine instructions for
/// SelectionDAG operations.
///
class X86DAGToDAGISel final : public SelectionDAGISel {bool runOnMachineFunction(MachineFunction &MF) override {// Reset the subtarget each time through.Subtarget = &MF.getSubtarget<X86Subtarget>();IndirectTlsSegRefs = MF.getFunction().hasFnAttribute("indirect-tls-seg-refs");// OptFor[Min]Size are used in pattern predicates that isel is matching.OptForMinSize = MF.getFunction().hasMinSize();assert((!OptForMinSize || MF.getFunction().hasOptSize()) &&"OptForMinSize implies OptForSize");SelectionDAGISel::runOnMachineFunction(MF);return true;}
}bool SelectionDAGISel::runOnMachineFunction(MachineFunction &mf) {SelectAllBasicBlocks(Fn);
}void SelectionDAGISel::SelectAllBasicBlocks(const Function &Fn) {ReversePostOrderTraversal<const Function*> RPOT(&Fn);for (const BasicBlock *LLVMBB : RPOT) {SelectBasicBlock(Begin, BI, HadTailCall);}
}void SelectionDAGISel::SelectBasicBlock(BasicBlock::const_iterator Begin,BasicBlock::const_iterator End,bool &HadTailCall) {// Final step, emit the lowered DAG as machine code.CodeGenAndEmitDAG();
}void SelectionDAGISel::CodeGenAndEmitDAG() {// Run the DAG combiner in pre-legalize mode.{NamedRegionTimer T("combine1", "DAG Combining 1", GroupName,GroupDescription, TimePassesIsEnabled);CurDAG->Combine(BeforeLegalizeTypes, AA, OptLevel);}// ...// Third, instruction select all of the operations to machine code, adding the// code to the MachineBasicBlock.{NamedRegionTimer T("isel", "Instruction Selection", GroupName,GroupDescription, TimePassesIsEnabled);DoInstructionSelection();}
}

SelectionDAGBuilder 是构建 SelectionDAG 的入口,通过一组 `SelectionDAGBuilder::Visit*` 来进行 SelectionDAG 的构建,想要观察对于 store instruction 这种可能有副作用的指令是怎么创建 chain dependence 的话,可以通过 `SelectionDAGBuilder::visitStore()`。

The initial SelectionDAG is naïvely peephole expanded from the LLVM input by the SelectionDAGBuilder class. The intent of this pass is to expose as much low-level, target-specific details to the SelectionDAG as possible. This pass is mostly hard-coded (e.g. an LLVM add turns into an SDNode add while a getelementptr is expanded into the obvious arithmetic). This pass requires target-specific hooks to lower calls, returns, varargs, etc. For these features, the TargetLowering interface is used.

SelectionDAG ISel

在执行真正的 selection 之前,有很多的步骤,例如 dag combine, legalize 等等优化的过程。这里专注杂 instruction selection 的部分。

MatcherTable

MatcherTable 是 SelectionDAGISel 中比较基础的一个数据,这里先看一下这个 MatcherTable 长什么样子,有以下几点需要注意:

  • 它是一个 unsigned char 超大数组可能会有上百万个元素,基于什么由谁生成的?被谁用了?

  • 有一堆 OPC_* 开头的枚举类型,它们是做什么的?分别代表什么意思?

  • 里面有一些 TARGET_VAL(ISD::OR)TARGET_VAL 是什么意思?ISD::OR 又是什么意思?

  • 其中有很多注释,它们分别表示什么意思?

// build/lib/Target/X86/X86GenDAGISel.inc
/*===- TableGen'erated file -------------------------------------*- C++ -*-===*\
|*                                                                            *|
|* DAG Instruction Selector for the X86 target                                *|
|*                                                                            *|
|* Automatically generated file, do not edit!                                 *|
|*                                                                            *|
\*===----------------------------------------------------------------------===*/#define TARGET_VAL(X) X & 255, unsigned(X) >> 8static const unsigned char MatcherTable[] = {
/*     0*/ OPC_SwitchOpcode /*496 cases */, 74|128,121/*15562*/, TARGET_VAL(ISD::STORE),// ->15567
/*     5*/  OPC_RecordMemRef,
/*     6*/  OPC_RecordNode, // #0 = 'st' chained node
/*     7*/  OPC_Scope, 71|128,7/*967*/, /*->977*/ // 9 children in Scope
/*    10*/   OPC_RecordChild1, // #1 = $src
/*    11*/   OPC_Scope, 60, /*->73*/ // 24 children in Scope
/*    13*/    OPC_CheckChild1Type, MVT::v4f32,
/*    15*/    OPC_RecordChild2, // #2 = $dst
/*    16*/    OPC_CheckPredicate6,  // Predicate_unindexedstore
/*    17*/    OPC_CheckPredicate7,  // Predicate_store
/*    18*/    OPC_CheckPredicate, 42, // Predicate_nontemporalstore
/*    20*/    OPC_CheckPredicate, 49, // Predicate_alignednontemporalstore
/*    22*/    OPC_Scope, 15, /*->39*/ // 3 children in Scope
/*    24*/     OPC_CheckPatternPredicate7, // (Subtarget->hasAVX()) && (!Subtarget->hasVLX())
/*    25*/     OPC_CheckComplexPat0, /*#*/2, // selectAddr:$dst #3 #4 #5 #6 #7
/*    27*/     OPC_EmitMergeInputChains1_0,
/*    28*/     OPC_MorphNodeTo0, TARGET_VAL(X86::VMOVNTPSmr), 0|OPFL_Chain|OPFL_MemRefs,6/*#Ops*/, 3, 4, 5, 6, 7, 1, // Src: (st VR128:{ *:[v4f32] }:$src, addr:{ *:[iPTR] }:$dst)<<P:Predicate_unindexedstore>><<P:Predicate_store>><<P:Predicate_nontemporalstore>><<P:Predicate_alignednontemporalstore>> - Complexity = 422// Dst: (VMOVNTPSmr addr:{ *:[iPTR] }:$dst, VR128:{ *:[v4f32] }:$src)
/*    39*/    /*Scope*/ 16, /*->56*/
/*    40*/     OPC_CheckPatternPredicate, 15, // (Subtarget->hasSSE1() && !Subtarget->hasAVX())
/*    42*/     OPC_CheckComplexPat0, /*#*/2, // selectAddr:$dst #3 #4 #5 #6 #7
/*    44*/     OPC_EmitMergeInputChains1_0,// ...}

首先这个表格位于 X86GenDAGISel.inc,是基于 llvm/lib/Target/X86/X86.td 生成的,我们可以使用下面的命令来生成这个文件。

➜  llvm git:(release/18.x) ../build/bin/llvm-tblgen -gen-dag-isel ./lib/Target/X86/X86.td -I=include -I=lib/Target/X86 

OPC_*定义在SelectionDAGISel的内部枚举类型BuiltinOpcodes中,下面划知识点,这个枚举类型会被 DAG state machine 用到。我们可以看到这些操作,有的是 Record Node,有的是 CaptureGlueInput,有的是 Move Child,有的是 Move Parent,有的是 Switch Type等等,应该是 state machine 状态转换的操作。行首注释与状态枚举之间的缩进长度指示了该状态的所属的层级举例而言对于pattern (add a, (sub b, c)), 检查操作数b的范围与检查操作数c的范围两个状态是平级的,检查操作数字a的范围肯定优先于检查操作数 b 的范围(先匹配树的根节点,再叶子节点)。 利用缩进可以图形化阅读状态跳转表。

对于类似于 ISD::OR 的类型来说,它们的定义如下:

//===--------------------------------------------------------------------===//
/// ISD::NodeType enum - This enum defines the target-independent operators
/// for a SelectionDAG.
///
/// Targets may also define target-dependent operator codes for SDNodes. For
/// example, on x86, these are the enum values in the X86ISD namespace.
/// Targets should aim to use target-independent operators to model their
/// instruction sets as much as possible, and only use target-dependent
/// operators when they have special requirements.
///
/// Finally, during and after selection proper, SNodes may use special
/// operator codes that correspond directly with MachineInstr opcodes. These
/// are used to represent selected instructions. See the isMachineOpcode()
/// and getMachineOpcode() member functions of SDNode.
///
enum NodeType {// .../// Bitwise operators - logical and, logical or, logical xor.AND,OR,XOR,// ...
}

但是除此之外在 MatcherTable 中也有 X86::VMOVNTPSmr 这样的标识,这类表示就是 X86 自己的定义,它们全部定义在 build/lib/Target/X86/X86GenAsmMatcher.inc 中。

static const MatchEntry MatchTable0[] = {{ 0 /* aaa */, X86::AAA, Convert_NoOperands, AMFBS_Not64BitMode, {  }, },{ 4 /* aad */, X86::AAD8i8, Convert__imm_95_10, AMFBS_Not64BitMode, {  }, },// ...{ 14029 /* vmovntps */, X86::VMOVNTPSmr, Convert__Mem1285_1__Reg1_0, AMFBS_None, { MCK_FR16, MCK_Mem128 }, },// ...
}

类似于 X86::VMOVNTPSmr 这种标识基本上可以认为是 target-dependent operator code,与指令基本上有一一对应的关系。现在我们知道了 MatcherTable 中包含了一些和 state machine 相关的内容,这些内容涉及到 static machine 中的 state 和 转移的动作,同时包含一些 LLVM 指令选择时抽象出来的 MVTISD(target-independent operator code),以及 target 相关的 opcode(target-dependent)。那么 MatcherTable 中的一些注释代表什么意思呢?这些注释我们需要搭配着示例来解释。

void X86DAGToDAGISel::Select(SDNode *Node) {switch (Opcode) {default: break;// ...case Intrinsic::x86_tileloadd64:case Intrinsic::x86_tileloaddt164:case Intrinsic::x86_tilestored64: {}}SelectCode(Node);
}

整个过程的入口函数是 `llvm::X86DAGToDAGISel::Select` ,前半部分主要是 Intrinsic 的 select,最终会调用 `X86DAGToDAGISel::SelectCode`,而最终会调用 `llvm::SelectionDAGISel::SelectCodeCommon`,该函数是核心(它叫什么名字无所谓,关键是它的整个逻辑)。

先感受下核心函数大致分为几个部分,这里的核心是

  • 首先会初始化此次为 SDNode 选择指令所需要的数据结构,MatchScopesRecoredNodesInputChainInputGlue(这些数据结构在注释中都写明了它的用途)

  • 一个 while 循环不停地根据 Opcode 来选择执行不同的动作,或更新当前状态,或跳转到下一状态

  • 如果在匹配的过程中,发现匹配失败,如何进行回退,如何从所谓的上,也就是MatchScopes回溯到前一个状态选择另外的状态进行匹配

以代码中的 `mul` 指令为例,看看它是怎么选择的。在 state machine 转起来之前,先获取到 SDNode 的 `Opcode ISD::MUL`,它对应的 MatcherTable Index 是 57288(SelectCodeCommon会预先将各个 Opcode 在 MatcherTable 中对应的 Index 给缓存下来放到 OpcodeOffset,下面就让整个过程转起来。

%mul = mul nsw i64 %0, %1
/* 96464*/ /*SwitchOpcode*/ 79|128,15/*1999*/, TARGET_VAL(ISD::MUL),// ->98467
/* 96468*/  OPC_Scope, 94, /*->96564*/ // 9 children in Scope
/* 96470*/   OPC_MoveChild0,
/* 96471*/   OPC_CheckOpcode, TARGET_VAL(ISD::LOAD),
/* 96474*/   OPC_RecordMemRef,
/* 96475*/   OPC_RecordNode, // #0 = 'ld' chained node
/* 96476*/   OPC_CheckFoldableChainNode,
/* 96477*/   OPC_RecordChild1, // #1 = $src1
/* 96478*/   OPC_CheckPredicate2,  // Predicate_unindexedload
/* 96479*/   OPC_Scope, 27, /*->96508*/ // 3 children in Scope
/* 96481*/    OPC_CheckPredicate1,  // Predicate_load
/* 96482*/    OPC_MoveSibling1,
/* 96483*/    OPC_CheckOpcode, TARGET_VAL(ISD::Constant),
/* 96486*/    OPC_RecordNode, // #2 = $src2
/* 96487*/    OPC_CheckPredicate, 24, // Predicate_i64immSExt32
/* 96489*/    OPC_MoveParent,
/* 96490*/    OPC_CheckTypeI64,
/* 96491*/    OPC_CheckComplexPat0, /*#*/1, // selectAddr:$src1 #3 #4 #5 #6 #7
/* 96493*/    OPC_EmitMergeInputChains1_0,
/* 96494*/    OPC_EmitConvertToTarget2,
/* 96495*/    OPC_MorphNodeTo2, TARGET_VAL(X86::IMUL64rmi32), 0|OPFL_Chain|OPFL_MemRefs,

MatcherTable

llc test.ll -debug-only=isel -O3 --debugFastISel is disabled=== imulOptimized legalized selection DAG: %bb.0 'imul:entry'
SelectionDAG has 10 nodes:t0: ch,glue = EntryTokent4: i64,ch = CopyFromReg t0, Register:i64 %1t2: i64,ch = CopyFromReg t0, Register:i64 %0t5: i64 = mul nsw t4, t2t8: ch,glue = CopyToReg t0, Register:i64 $rax, t5t9: ch = X86ISD::RET_GLUE t8, TargetConstant:i32<0>, Register:i64 $rax, t8:1===== Instruction selection begins: %bb.0 'entry'ISEL: Starting selection on root node: t9: ch = X86ISD::RET_GLUE t8, TargetConstant:i32<0>, Register:i64 $rax, t8:1
ISEL: Starting pattern matchMorphed node: t9: ch = RET TargetConstant:i32<0>, Register:i64 $rax, t8, t8:1
ISEL: Match complete!ISEL: Starting selection on root node: t8: ch,glue = CopyToReg t0, Register:i64 $rax, t5ISEL: Starting selection on root node: t5: i64 = mul nsw t4, t2
ISEL: Starting pattern matchInitial Opcode index to 96468Match failed at index 96471Continuing at 96564Match failed at index 96568Continuing at 96739Match failed at index 96742Continuing at 96896TypeSwitch[i64] from 96898 to 96935Match failed at index 96935Continuing at 96948Match failed at index 96958Continuing at 97003Match failed at index 97004Continuing at 97015Match failed at index 97016Continuing at 97042Match failed at index 97043Continuing at 97068Morphed node: t5: i64,i32 = IMUL64rr nsw t4, t2
ISEL: Match complete!===== Instruction selection ends:Selected selection DAG: %bb.0 'imul:entry'
SelectionDAG has 11 nodes:t0: ch,glue = EntryTokent4: i64,ch = CopyFromReg t0, Register:i64 %1t2: i64,ch = CopyFromReg t0, Register:i64 %0t5: i64,i32 = IMUL64rr nsw t4, t2t8: ch,glue = CopyToReg t0, Register:i64 $rax, t5t10: i32 = Register $noregt9: ch = RET TargetConstant:i32<0>, Register:i64 $rax, t8, t8:1Total amount of phi nodes to update: 0
*** MachineFunction at end of ISel ***
# Machine code for function imul: IsSSA, TracksLiveness
Function Live Ins: $rdi in %0, $rsi in %1bb.0.entry:liveins: $rdi, $rsi%1:gr64 = COPY $rsi%0:gr64 = COPY $rdi%2:gr64 = nsw IMUL64rr %1:gr64(tied-def 0), %0:gr64, implicit-def dead $eflags$rax = COPY %2:gr64RET 0, $rax# End machine code for function imul.

整个过程类似于下图

注:上图来源于 https://www.cnblogs.com/Five100Miles/p/12903057.html,介绍的非常深入

According to a blog entry by Bendersky [30] – which at the time of writing provided the only documentation except for the LLVM code itself – the instruction selector is basically a greedy DAG-to-DAG rewriter, where machine-independent DAG representations of basic blocks are rewritten into machine-dependent DAG representations. 

The patterns, which are limited to trees, are expressed in a machine description format that allows common features to be factored out into abstract instructions.

Using a tool called TableGen, the machine description is then expanded into complete tree patterns which are processed by a matcher generator.

The matcher generator first performs a lexicographical sort on the patterns:

  1. first by decreasing complexity, which is the sum of the pattern size and a constant ( this can be tweaked to give higher priority for particular machine instructions);
  2. then by increasing cost;
  3. and lastly by increasing size of the output pattern.

Once sorted each pattern is converted into a recursive matcher which is essentially a small program that checks whether the pattern matches at a given node in the expression DAG. The table is arranged such that the patterns are checked in the order of the lexicographical sort. As a match is found the pattern is greedily selected and the matched subgraph is replaced with the output (usually a single node) of the matched pattern. Although powerful and in extensive use, LLVM’s instruction selector has several drawbacks. The main disadvantage is that any pattern that cannot be handled by TableGen has to be handled manually through custom C functions. Since patterns are restricted to tree shapes this includes all multiple-output patterns. In addition, the greedy scheme compromises code quality. 

Survey on Instruction Selection

Global ISel

最原始的 proposal 来源于

  • [LLVMdev] [global-isel] Proposal for a global instruction selector
  • [GlobalISel] A Proposal for global instruction selection

按照下面的 motivation,SelectionDAG ISel 有一些问题,例如不是真正的 global instruction selector,慢,如 FastIsel 代码不共享,SelectionDAG 太 High Level 无法表示真正意义上的 Register 信息等等。

Motivation

Everybody loves to hate SelectionDAG, but it is still useful to make its shortcomings explicit. These are some of the goals for a new instruction selector architecture.
 

We want a global instruction selector.
SelectionDAG operates on a basic block at a time, and we have been forced to implement a number of hacks to work around that. For example, most of CodeGenPrepare is moving instructions around to make good local instruction selection more likely. Legalization of switches and selects must be done either before or after instruction selection because it requires creating new basic blocks.

A number of passes running after instruction selection are also mostly about cleaning up after the single-basic-block selector. This includes MachineCSE, MachineLICM, and the peephole pass.

We want a faster instruction selector.
The SelectionDAG process is quite heavyweight because it uses continuous CSE, a whole new IR, and a mandatory scheduling phase to linearize the DAG. By selecting directly to MI, we can avoid one IR translation phase. By using a linearized IR, scheduling becomes optional.

We want a shared code path for fast and good instruction selection.
Currently, the fast instruction selector used for -O0 builds is a completely separate code path. This is not healthy because it increases the likelihood of bugs in the fast path that were not present in the slow path. It would be better if the -O0 instruction selector were a trimmed down version of the full instruction selector.

We want an IR that represents ISA concepts better.
The SelectionDAG IR is very good at representing LLVM IR directly, but as the code is lowered to model target machine concepts, weird hacks are often required. This is evident in the way too many SDNodes required to represent a function call, or the many custom ISD nodes that targets need to define.

In many cases, custom target code knows exactly which instructions it wants to produce, and the IR should make it possible and easy to just emit the desired instructions directly. The MI intermediate representation isn't perfect either, and we should plan some MI improvements as well.

The SelectionDAG concept of legal types and their mapping to a single register class often causes problems. In some cases, it is necessary to lie about value types, just to get the instruction selector to do the right thing.

We want a more configurable instruction selector.

Weird targets have weird requirements, and it should be possible for targets to inject new passes into the instruction selection process. Sometimes, it may even be required to replace a standard pass.

SelectionDAG ISel 在 instruction selection 的同时完成 LLVM IR -> Machine IR 的转换。所以提出来了 Global ISel 的概念,中间也会涉及到一些转换。

 注:上图来源于 Global Instruction Selection(global-isel)

注:上图来源于 https://www.youtube.com/watch?v=S6SNs2ttdoA

但是按照目前的数据来看 Global ISel 比 SelectionDAG ISel 在编译耗时上有优势,性能上并没有 totally win。例如 https://www.youtube.com/watch?v=PEP0DfAT_N8 和 https://www.youtube.com/watch?v=S6SNs2ttdoA。本文不深入分析了

注:上图来源于 https://www.youtube.com/watch?v=F6GGbYtae3g

Reference

How to Write an LLVM Backend #4: Instruction Selection

LLVM笔记(10) - 指令选择(二) lowering https://sourcecodeartisan.com/2020/11/17/llvm-backend-4.html

https://www.youtube.com/watch?v=F6GGbYtae3g

https://www.youtube.com/watch?v=PEP0DfAT_N8

https://www.youtube.com/watch?v=S6SNs2ttdoA

https://llvm.org/devmtg/2017-10/slides/Bogner-Nandakumar-Sanders-Head%20First%20into%20GlobalISel.pdf

这篇关于LLVM Instruction Selection 笔记的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/963076

相关文章

【学习笔记】 陈强-机器学习-Python-Ch15 人工神经网络(1)sklearn

系列文章目录 监督学习:参数方法 【学习笔记】 陈强-机器学习-Python-Ch4 线性回归 【学习笔记】 陈强-机器学习-Python-Ch5 逻辑回归 【课后题练习】 陈强-机器学习-Python-Ch5 逻辑回归(SAheart.csv) 【学习笔记】 陈强-机器学习-Python-Ch6 多项逻辑回归 【学习笔记 及 课后题练习】 陈强-机器学习-Python-Ch7 判别分析 【学

系统架构师考试学习笔记第三篇——架构设计高级知识(20)通信系统架构设计理论与实践

本章知识考点:         第20课时主要学习通信系统架构设计的理论和工作中的实践。根据新版考试大纲,本课时知识点会涉及案例分析题(25分),而在历年考试中,案例题对该部分内容的考查并不多,虽在综合知识选择题目中经常考查,但分值也不高。本课时内容侧重于对知识点的记忆和理解,按照以往的出题规律,通信系统架构设计基础知识点多来源于教材内的基础网络设备、网络架构和教材外最新时事热点技术。本课时知识

论文阅读笔记: Segment Anything

文章目录 Segment Anything摘要引言任务模型数据引擎数据集负责任的人工智能 Segment Anything Model图像编码器提示编码器mask解码器解决歧义损失和训练 Segment Anything 论文地址: https://arxiv.org/abs/2304.02643 代码地址:https://github.com/facebookresear

数学建模笔记—— 非线性规划

数学建模笔记—— 非线性规划 非线性规划1. 模型原理1.1 非线性规划的标准型1.2 非线性规划求解的Matlab函数 2. 典型例题3. matlab代码求解3.1 例1 一个简单示例3.2 例2 选址问题1. 第一问 线性规划2. 第二问 非线性规划 非线性规划 非线性规划是一种求解目标函数或约束条件中有一个或几个非线性函数的最优化问题的方法。运筹学的一个重要分支。2

【C++学习笔记 20】C++中的智能指针

智能指针的功能 在上一篇笔记提到了在栈和堆上创建变量的区别,使用new关键字创建变量时,需要搭配delete关键字销毁变量。而智能指针的作用就是调用new分配内存时,不必自己去调用delete,甚至不用调用new。 智能指针实际上就是对原始指针的包装。 unique_ptr 最简单的智能指针,是一种作用域指针,意思是当指针超出该作用域时,会自动调用delete。它名为unique的原因是这个

查看提交历史 —— Git 学习笔记 11

查看提交历史 查看提交历史 不带任何选项的git log-p选项--stat 选项--pretty=oneline选项--pretty=format选项git log常用选项列表参考资料 在提交了若干更新,又或者克隆了某个项目之后,你也许想回顾下提交历史。 完成这个任务最简单而又有效的 工具是 git log 命令。 接下来的例子会用一个用于演示的 simplegit

记录每次更新到仓库 —— Git 学习笔记 10

记录每次更新到仓库 文章目录 文件的状态三个区域检查当前文件状态跟踪新文件取消跟踪(un-tracking)文件重新跟踪(re-tracking)文件暂存已修改文件忽略某些文件查看已暂存和未暂存的修改提交更新跳过暂存区删除文件移动文件参考资料 咱们接着很多天以前的 取得Git仓库 这篇文章继续说。 文件的状态 不管是通过哪种方法,现在我们已经有了一个仓库,并从这个仓

忽略某些文件 —— Git 学习笔记 05

忽略某些文件 忽略某些文件 通过.gitignore文件其他规则源如何选择规则源参考资料 对于某些文件,我们不希望把它们纳入 Git 的管理,也不希望它们总出现在未跟踪文件列表。通常它们都是些自动生成的文件,比如日志文件、编译过程中创建的临时文件等。 通过.gitignore文件 假设我们要忽略 lib.a 文件,那我们可以在 lib.a 所在目录下创建一个名为 .gi

取得 Git 仓库 —— Git 学习笔记 04

取得 Git 仓库 —— Git 学习笔记 04 我认为, Git 的学习分为两大块:一是工作区、索引、本地版本库之间的交互;二是本地版本库和远程版本库之间的交互。第一块是基础,第二块是难点。 下面,我们就围绕着第一部分内容来学习,先不考虑远程仓库,只考虑本地仓库。 怎样取得项目的 Git 仓库? 有两种取得 Git 项目仓库的方法。第一种是在本地创建一个新的仓库,第二种是把其他地方的某个

Git 的特点—— Git 学习笔记 02

文章目录 Git 简史Git 的特点直接记录快照,而非差异比较近乎所有操作都是本地执行保证完整性一般只添加数据 参考资料 Git 简史 众所周知,Linux 内核开源项目有着为数众多的参与者。这么多人在世界各地为 Linux 编写代码,那Linux 的代码是如何管理的呢?事实是在 2002 年以前,世界各地的开发者把源代码通过 diff 的方式发给 Linus,然后由 Linus