マシンIR（MIR）フォーマットリファレンスマニュアル¶

警告

これは開発途上のものです。

はじめに ¶

このドキュメントは、マシンIR（MIR）シリアル化フォーマットのリファレンスマニュアルです。MIRは、LLVMのマシン固有の中間表現を表すために使用される、人間が読み取れるシリアル化フォーマットです。

MIRシリアル化フォーマットは、LLVMのコード生成パスのテストに使用するために設計されています。

概要 ¶

MIRシリアル化フォーマットはYAMLコンテナを使用します。YAMLは標準的なデータシリアル化言語であり、YAML言語仕様の全文はyaml.orgで読むことができます。

MIRファイルは、一連のYAMLドキュメントに分割されます。最初のドキュメントには、オプションで埋め込まれたLLVM IRモジュールを含めることができ、残りのドキュメントにはシリアル化されたマシン関数が含まれています。

MIRテストガイド ¶

MIRフォーマットは、2つの異なる方法でテストに使用できます。

llcで-run-passオプションを使用して、単一のコード生成パスを呼び出すMIRテストを作成できます。
既存の、または新しいLLVMアセンブリテストでllcの-stop-afterオプションを使用し、特定のコード生成パスのMIR出力を確認できます。

個々のコード生成パスのテスト ¶

llcの-run-passオプションを使用すると、単一のコード生成パスだけを呼び出すMIRテストを作成できます。このオプションを使用すると、llcは入力MIRファイルを解析し、指定されたコード生成パスを実行して、結果のMIRコードを出力します。

テストの入力MIRファイルは、llcの-stop-afterまたは-stop-beforeオプションを使用して生成できます。たとえば、ポストレジスタ割り当て擬似命令展開パスのテストを作成したい場合は、テストしようとしているパスの直前に実行されるため、-stop-afterオプションにマシンコピー伝搬パスを指定できます。

llc -stop-after=machine-cp bug-trigger.ll -o test.mir

同じパスが複数回実行される場合は、名前の後にコンマで区切った実行インデックスを含めることができます。

llc -stop-after=dead-mi-elimination,1 bug-trigger.ll -o test.mir

入力MIRファイルの生成後、-run-passオプションを使用する実行行を追加する必要があります。X86-64でポストレジスタ割り当て擬似命令展開パスをテストするには、以下のような実行行を使用できます。

# RUN: llc -o - %s -mtriple=x86_64-- -run-pass=postrapseudos | FileCheck %s

MIRファイルはターゲット依存であるため、ターゲット固有のテストディレクトリ（lib/CodeGen/TARGETNAME）に配置する必要があります。また、実行行または埋め込まれたLLVM IRモジュールでターゲットトリプルまたはターゲットアーキテクチャを指定する必要があります。

MIRファイルの簡素化 ¶

-stop-after/-stop-beforeから出力されるMIRコードは非常に冗長です。テストは、簡素化することでよりアクセスしやすく、将来性が高まります。

llcで-simplify-mirオプションを使用します。
マシン関数属性には、多くの場合、デフォルト値があります。または、デフォルト値でもテストは同様に機能します。これの典型的な候補は、alignment:、exposesReturnsTwice、legalized、regBankSelected、selectedです。frameInfoセクション全体は、関数に特別なフレーム使用がない場合は、多くの場合不要です。一方、tracksRegLivenessは、ブロックライブインリストを考慮する一部のパスには、多くの場合必要です。
(グローバル) liveins:リストは、通常、初期命令選択パスでのみ興味深いものであり、後続のパスをテストする場合は削除できます。一方、ブロックごとのliveins:は、tracksRegLivenessがtrueの場合は必要です。
ブロックsuccessors:リストの分岐確率データは、テストがそれに依存しない場合は削除できます。例：successors: %bb.1(0x40000000), %bb.2(0x40000000)はsuccessors: %bb.1, %bb.2に置き換えることができます。
MIRコードには、IRモジュール全体が含まれています。これは、グローバル変数、外部関数の参照、関数属性、メタデータ、デバッグ情報にはMIRに相当するものがないためです。代わりに、一部のMIRデータはIR構造を参照します。テストがそれに依存しない場合は、多くの場合、それらを除去できます。
エイリアス解析はIR値に対して実行されます。これらは、MIRのメモリオペランドによって参照されます。例：:: (load 8 from %ir.foobar, !alias.scope !9)。テストが（良好な）エイリアス解析に依存しない場合、参照を削除できます：:: (load 8)
MIRブロックは、デバッグ印刷、プロファイル情報、またはデバッグ位置のためにIRブロックを参照できます。例：MIRのbb.42.myblockはIRブロックmyblockを参照します。.myblock参照を削除し、単にbb.42を使用することは通常可能です。
IRを参照するメモリオペランドまたはブロックがない場合、IR関数はdefine @func() { ret void }のようなパラメータなしのダミー関数に置き換えることができます。
ダミー関数のみを含む場合（上記を参照）、MIRファイルのIRセクション全体を削除できます。この場合、.mirローダーは自動的にIR関数を生成します。

制限事項 ¶

現在、MIRフォーマットには、シリアル化できる状態に関していくつかの制限があります。

ターゲット固有のMachineFunctionInfoサブクラスのターゲット固有の状態は、現時点ではシリアル化されていません。
ターゲット固有のMachineConstantPoolValueサブクラス（ARMおよびSystemZバックエンド内）は、現時点ではシリアル化されていません。
MCSymbolマシンオペランドは、一時的なシンボルまたはローカルシンボルをサポートしていません。
MachineModuleInfoの状態の多くはシリアル化されていません。現時点では、MMIからのCFI命令と変数デバッグ情報のみがシリアル化されています。

これらの制限により、MIRフォーマットでテストできる内容に制限が課せられます。現時点では、一時的なシンボルまたはローカルMCSymbolオペランドの状態、またはMMIの例外処理の状態に依存する動作をテストしたいテストは、MIRフォーマットを使用できません。同様に、ターゲット固有のMachineFunctionInfoまたはMachineConstantPoolValueサブクラスの状態に依存する動作をテストするテストは、現時点ではMIRフォーマットを使用できません。

上位構造 ¶

埋め込みモジュール ¶

最初のYAMLドキュメントにYAMLブロックリテラル文字列が含まれている場合、MIRパーサーはこの文字列を、埋め込まれたLLVM IRモジュールを表すLLVMアセンブリ言語文字列として扱います。LLVMモジュールを含むYAMLドキュメントの例を次に示します。

define i32 @inc(ptr %x) {
entry:
  %0 = load i32, ptr %x
  %1 = add i32 %0, 1
  store i32 %1, ptr %x
  ret i32 %1
}

マシン関数 ¶

残りのYAMLドキュメントには、マシン関数が含まれています。このようなYAMLドキュメントの例を次に示します。

---
name:            inc
tracksRegLiveness: true
liveins:
  - { reg: '$rdi' }
callSites:
  - { bb: 0, offset: 3, fwdArgRegs:
      - { arg: 0, reg: '$edi' } }
body: |
  bb.0.entry:
    liveins: $rdi

    $eax = MOV32rm $rdi, 1, _, 0, _
    $eax = INC32r killed $eax, implicit-def dead $eflags
    MOV32mr killed $rdi, 1, _, 0, _, $eax
    CALL64pcrel32 @foo <regmask...>
    RETQ $eax
...

上記のドキュメントは、マシン関数内のさまざまなプロパティとデータ構造を表す属性で構成されています。

属性nameは必須であり、その値はこのマシン関数が基づいている関数の名前と同一である必要があります。

属性bodyはYAMLブロックリテラル文字列です。その値は、関数のマシン基本ブロックとそのマシン命令を表します。

属性callSitesは、コールサイト情報を表現したもので、コール命令と、コール引数を転送するために使用されるレジスタを追跡します。

機械命令フォーマットリファレンス ¶

機械の基本ブロックとその命令は、カスタムで人間が読み取れるシリアル化言語を使用して表現されます。この言語は、機械関数の本体に対応するYAMLブロックリテラル文字列で使用されます。

この言語を使用するソース文字列には、機械の基本ブロックのリストが含まれており、それらは以下のセクションで説明されています。

機械基本ブロック ¶

機械基本ブロックは、ブロックのIDを含む単一のブロック定義ソース構成で定義されます。以下の例では、IDが0と1の2つのブロックを定義しています。

bb.0:
  <instructions>
bb.1:
  <instructions>

機械基本ブロックには名前を付けることもできます。ブロックの定義では、IDの後に指定する必要があります。

bb.0.entry:       ; This block's name is "entry"
   <instructions>

ブロックの名前は、この機械ブロックの基になっているIRブロックの名前と同一である必要があります。

ブロック参照 ¶

機械基本ブロックは、ID番号で識別されます。個々のブロックは、以下の構文を使用して参照されます。

%bb.<id>

例

%bb.0

以下の構文もサポートされていますが、ブロック参照には前の構文が推奨されます。

%bb.<id>[.<name>]

例

%bb.1.then

サクセサ ¶

機械基本ブロックのサクセサは、命令の前に指定する必要があります。

bb.0.entry:
  successors: %bb.1.then, %bb.2.else
  <instructions>
bb.1.then:
  <instructions>
bb.2.else:
  <instructions>

サクセサブロックの後に角括弧で分岐重みを指定できます。以下の例では、分岐重みが32と16の2つのサクセサを持つブロックを定義しています。

bb.0.entry:
  successors: %bb.1.then(32), %bb.2.else(16)

ライブインレジスタ ¶

機械基本ブロックのライブインレジスタは、命令の前に指定する必要があります。

bb.0.entry:
  liveins: $edi, $esi

ライブインレジスタとサクセサのリストは空にすることができます。この言語では、複数のライブインレジスタとサクセサのリストも許可されており、パーサーによって1つのリストに結合されます。

その他の属性 ¶

属性IsAddressTaken、IsLandingPad、IsInlineAsmBrIndirectTarget、およびAlignmentは、ブロックの定義の後に角括弧で指定できます。

bb.0.entry (address-taken):
  <instructions>
bb.2.else (align 4):
  <instructions>
bb.3(landing-pad, align 4):
  <instructions>
bb.4 (inlineasm-br-indirect-target):
  <instructions>

Alignmentはバイト単位で指定され、2の累乗である必要があります。

機械命令 ¶

機械命令は、名前、機械オペランド、命令フラグ、および機械メモリオペランドで構成されています。

命令の名前は通常、オペランドの前に指定されます。以下の例は、単一の機械オペランドを持つX86 RETQ命令のインスタンスを示しています。

RETQ $eax

ただし、機械命令に1つ以上の明示的に定義されたレジスタオペランドがある場合、命令の名前はそれらの後に指定する必要があります。以下の例は、3つの定義済みレジスタオペランドを持つAArch64 LDPXpost命令のインスタンスを示しています。

$sp, $fp, $lr = LDPXpost $sp, 2

命令名は、ターゲットの*InstrInfo.tdファイルからの正確な定義を使用してシリアル化され、大文字と小文字が区別されます。つまり、TSTriとtSTRiのような類似した命令名は、異なる機械命令を表します。

命令フラグ ¶

フラグframe-setupまたはframe-destroyは、命令名の前に指定できます。

$fp = frame-setup ADDXri $sp, 0, 0

$x21, $x20 = frame-destroy LDPXi $sp

バンドルされた命令 ¶

バンドルされた命令の構文は以下のとおりです。

BUNDLE implicit-def $r0, implicit-def $r1, implicit $r2 {
  $r0 = SOME_OP $r2
  $r1 = ANOTHER_OP internal $r0
}

最初の命令は多くの場合、バンドルヘッダーです。{と}の間の命令は、最初の命令とバンドルされます。

レジスタ ¶

レジスタは、機械命令シリアル化言語の主要なプリミティブの1つです。主にレジスタ機械オペランドで使用されますが、基本ブロックのライブインリストなど、他の多くの場所でも使用できます。

物理レジスタは、名前と「$」プレフィックスシギルによって識別されます。以下の構文を使用します。

$<name>

以下の例は、3つのX86物理レジスタを示しています。

$eax
$r15
$eflags

仮想レジスタは、ID番号と「%」シギルによって識別されます。以下の構文を使用します。

%<id>

例

%0

ヌルレジスタは、アンダースコア（'_'）を使用して表されます。「$noreg」という名前のレジスタを使用して表すこともできますが、前の構文が推奨されます。

機械オペランド ¶

18種類の機械オペランドがあり、すべてシリアル化できます。

イミディエイトオペランド ¶

イミディエイト機械オペランドは、型のない64ビット符号付き整数です。以下の例は、イミディエイト機械オペランド-42を持つX86 MOV32ri命令のインスタンスを示しています。

$eax = MOV32ri -42

イミディエイトオペランドは、機械命令に以下のオペコードのいずれかがある場合、サブレジスタインデックスを表すためにも使用されます。

EXTRACT_SUBREG
INSERT_SUBREG
REG_SEQUENCE
SUBREG_TO_REG

これが当てはまる場合、機械オペランドはターゲットに従って出力されます。

例として

AArch64RegisterInfo.tdでは

def sub_32 : SubRegIndex<32>;

3番目のオペランドが値15（ターゲット依存値）のイミディエイトである場合、命令のオペコードとオペランドのインデックスに基づいて、オペランドは%subreg.sub_32として出力されます。

%1:gpr64 = SUBREG_TO_REG 0, %0, %subreg.sub_32

64ビットを超える整数の場合、ConstantIntを使用してイミディエイトをAPInt（LLVMの任意精度整数）に格納する特別な機械オペランドMO_CImmediateを使用します。

レジスタオペランド ¶

レジスタプリミティブは、レジスタ機械オペランドを表すために使用されます。レジスタオペランドには、オプションのレジスタフラグ、サブレジスタインデックス、およびタイドされたレジスタオペランドへの参照を含めることができます。レジスタオペランドの完全な構文を以下に示します。

[<flags>] <register> [ :<subregister-idx-name> ] [ (tied-def <tied-op>) ]

この例は、さまざまなレジスタフラグを持つ5つのレジスタオペランドを持つX86 XOR32rr命令のインスタンスを示しています。

dead $eax = XOR32rr undef $eax, undef $eax, implicit-def dead $eflags, implicit-def $al

レジスタフラグ ¶

以下の表は、対応する内部llvm::RegState表現と共に、考えられるすべてのレジスタフラグを示しています。

フラグ	内部値	意味
`implicit`	`RegState::Implicit`	出力されないレジスタ（例：キャリー、または一時的な結果）。
`implicit-def`	`RegState::ImplicitDefine`	`implicit`と`def`
`def`	`RegState::Define`	レジスタ定義。
`dead`	`RegState::Dead`	使用されない定義。
`killed`	`RegState::Kill`	レジスタの最後の使用。
`undef`	`RegState::Undef`	レジスタの値は重要ではありません。
`internal`	`RegState::InternalRead`	レジスタは、同じ命令またはバンドル内で定義されている値を読み取ります。
`early-clobber`	`RegState::EarlyClobber`	レジスタの定義は使用よりも前に発生します。
`debug-use`	`RegState::Debug`	レジスタの「使用」はデバッグ目的です。
`renamable`	`RegState::Renamable`	名前を変更できるレジスタ。

サブレジスタインデックス ¶

レジスタ機械オペランドは、サブレジスタインデックスを使用してレジスタの一部を参照できます。以下の例は、X86 sub_8bitサブレジスタインデックスを使用して、32ビット仮想レジスタ0の下位8ビットを8ビット仮想レジスタ1にコピーするCOPY擬似命令のインスタンスを示しています。

%1 = COPY %0:sub_8bit

サブレジスタインデックスの名前はターゲット固有であり、通常はターゲットの*RegisterInfo.tdファイルで定義されています。

定数プールインデックス ¶

定数プールインデックス（CPI）オペランドは、関数のMachineConstantPoolにおけるそのインデックスとオフセットを使用して出力されます。

たとえば、インデックスが1でオフセットが8のCPI

%1:gr64 = MOV64ri %const.1 + 8

インデックスが0でオフセットが-12のCPI

%1:gr64 = MOV64ri %const.0 - 12

定数プールエントリは、LLVM IR Constantまたはターゲット固有のMachineConstantPoolValueにバインドされます。すべての関数の定数をシリアル化する場合、以下の形式が使用されます。

constants:
  - id:               <index>
    value:            <value>
    alignment:        <alignment>
    isTargetSpecific: <target-specific>

ここで

<index>は32ビット符号なし整数です。
<value> は LLVM IR定数です。
<alignment> はバイト単位で指定された32ビットの符号なし整数であり、2のべき乗でなければなりません。
<target-specific> は真または偽のいずれかです。

例

constants:
  - id:               0
    value:            'double 3.250000e+00'
    alignment:        8
  - id:               1
    value:            'g-(LPC0+8)'
    alignment:        4
    isTargetSpecific: true

グローバル値オペランド ¶

グローバル値マシンオペランドは、埋め込まれたLLVM IRモジュールからのグローバル値を参照します。以下の例は、Gという名前のグローバル値オペランドを持つX86のMOV64rm命令のインスタンスを示しています。

$rax = MOV64rm $rip, 1, _, @G, _

名前付きグローバル値は、「@」プレフィックス付きの識別子を使用して表されます。識別子が正規表現[-a-zA-Z$._][-a-zA-Z$._0-9]*に一致しない場合、この識別子は引用符で囲む必要があります。

名前のないグローバル値は、「@」プレフィックス付きの符号なし数値を使用して表されます。次の例を参照してください。@0、@989。

ターゲット依存のインデックスオペランド ¶

ターゲットインデックスオペランドは、ターゲット固有のインデックスとオフセットです。ターゲット固有のインデックスは、ターゲット固有の名前と正または負のオフセットを使用して出力されます。

たとえば、amdgpu-constdata-startは、AMDGPUバックエンドでインデックス0に関連付けられています。したがって、インデックス0とオフセット8を持つターゲットインデックスオペランドがある場合

$sgpr2 = S_ADD_U32 _, target-index(amdgpu-constdata-start) + 8, implicit-def _, implicit-def _

ジャンプテーブルインデックスオペランド ¶

インデックス0のジャンプテーブルインデックスオペランドは、次のように出力されます。

tBR_JTr killed $r0, %jump-table.0

マシンジャンプテーブルエントリには、MachineBasicBlocksのリストが含まれています。すべての関数のジャンプテーブルエントリをシリアル化する際には、次の形式が使用されます。

jumpTable:
  kind:             <kind>
  entries:
    - id:             <index>
      blocks:         [ <bbreference>, <bbreference>, ... ]

ここで<kind>は、ジャンプテーブルがどのように表現され、出力されるか（プレーンアドレス、リロケーション、PICなど）を示し、各<index>は32ビットの符号なし整数であり、blocksにはマシン基本ブロック参照のリストが含まれています。

例

jumpTable:
  kind:             inline
  entries:
    - id:             0
      blocks:         [ '%bb.3', '%bb.9', '%bb.4.d3' ]
    - id:             1
      blocks:         [ '%bb.7', '%bb.7', '%bb.4.d3', '%bb.5' ]

外部シンボルオペランド ¶

外部シンボルオペランドは、「&」プレフィックス付きの識別子を使用して表されます。識別子は「」で囲まれ、特別な非印刷可能な文字が含まれている場合はエスケープされます。

例

CALL64pcrel32 &__stack_chk_fail, csr_64, implicit $rsp, implicit-def $rsp

MCSymbolオペランド ¶

MCSymbolオペランドは、MCSymbolへのポインタを保持しています。MIRにおけるこのオペランドの制限については、制限事項を参照してください。

構文は次のとおりです。

EH_LABEL <mcsymbol Ltmp1>

デバッグ命令参照オペランド ¶

デバッグ命令参照オペランドは、それぞれ命令と命令内のオペランドを参照するインデックスのペアです。命令参照位置を参照してください。

以下の例では、命令1、オペランド0への参照を使用しています。

DBG_INSTR_REF !123, !DIExpression(DW_OP_LLVM_arg, 0), dbg-instr-ref(1, 0), debug-location !456

CFIIndexオペランド ¶

CFI Indexオペランドは、関数ごとのサイドテーブルMachineFunction::getFrameInstructions()へのインデックスを保持しており、MachineFunction内のすべてのフレーム命令を参照します。CFI_INSTRUCTIONには複数のオペランドが含まれているように見える場合がありますが、含まれるオペランドはCFI Indexのみです。他のオペランドはMCCFIInstructionオブジェクトによって追跡されます。

構文は次のとおりです。

CFI_INSTRUCTION offset $w30, -16

これは、後でMCレイヤーで次のように出力される可能性があります。

.cfi_offset w30, -16

IntrinsicIDオペランド ¶

Intrinsic IDオペランドには、一般的なIntrinsic IDまたはターゲット固有のIDが含まれています。

returnaddress Intrinsicの構文は次のとおりです。

$x0 = COPY intrinsic(@llvm.returnaddress)

述語オペランド ¶

述語オペランドには、CmpInst::PredicateからのIR述語が含まれます（ICMP_EQなど）。

int eq述語ICMP_EQの場合、構文は次のとおりです。

%2:gpr(s32) = G_ICMP intpred(eq), %0, %1

コメント ¶

マシンオペランドには、C/C++スタイルのコメントを含めることができます。これは、/*と*/で囲まれた注釈であり、たとえば即値オペランドの可読性を向上させるために使用されます。以下の例では、ARM命令EORとBCC、および即値オペランド14と0に、条件コード（CC）の定義、つまりalwaysとeq条件コードの注釈が付けられています。

dead renamable $r2, $cpsr = tEOR killed renamable $r2, renamable $r1, 14 /* CC::always */, $noreg
t2Bcc %bb.4, 0 /* CC:eq */, killed $cpsr

これらの注釈はコメントであるため、MIパーサーによって無視されます。コメントは、InstrInfoのフックcreateMIROperandComment()をオーバーライドすることで追加またはカスタマイズできます。

デバッグ情報構造体 ¶

MIRファイルのデバッグ情報のほとんどは、埋め込まれたモジュールのメタデータにあります。マシン関数内では、そのメタデータはさまざまな構造体によって参照され、ソース位置と変数位置が記述されます。

ソース位置 ¶

すべてのMIR命令には、すべてのオペランドとシンボルの後、メモリオペランドの前には、オプションでDILocationメタデータノードへの参照を付けることができます。

$rbp = MOV64rr $rdi, debug-location !12

ソース位置の付加は、LLVM-IRの!dbgメタデータの付加と同義です。ソース位置の付加がない場合は、マシン命令に空のDebugLocオブジェクトが表されます。

固定変数位置 ¶

変数位置を指定するにはいくつかの方法があります。最も単純な方法は、スタック上に永久的に配置されている変数を記述することです。マシン関数のstackまたはfixedStack属性には、変数、スコープ、および修飾する位置修飾子が指定されています。

- { id: 0, name: offset.addr, offset: -24, size: 8, alignment: 8, stack-id: default,
 4  debug-info-variable: '!1', debug-info-expression: '!DIExpression()',
    debug-info-location: '!2' }

ここで

debug-info-variableは、DILocalVariableメタデータノードを識別します。
debug-info-expressionは、変数位置に修飾子を追加します。
debug-info-locationは、DILocationメタデータノードを識別します。

これらのメタデータ属性は、#dbg_declare IRデバッグレコードのオペランドに対応しています。ソースレベルデバッグのドキュメントを参照してください。

可変変数位置 ¶

スタック上に常に存在しないか、位置が変わる変数は、DBG_VALUEメタマシン命令で指定されます。これは#dbg_value IRレコードと同義であり、次のように記述されます。

DBG_VALUE $rax, $noreg, !123, !DIExpression(), debug-location !456

それぞれのオペランドは

レジスタ、即値、またはフレームインデックスなどのマシン位置を識別します。
$noreg、または間接参照の追加レベルを追加する必要がある場合は即値0です。
DILocalVariableメタデータノードを識別します。
変数位置を修飾する式を、インラインまたはメタデータノード参照として指定します。

ソース位置は、変数のスコープのDILocationを識別します。2番目のオペランド（IsIndirect）は非推奨であり、削除される予定です。変数位置の追加の修飾子はすべて、式メタデータを使用して行う必要があります。

命令参照位置 ¶

この実験的な機能は、変数の値の指定と、変数がその値を取るプログラムポイントの分離を目指しています。変数の値の変化は、DBG_VALUEメタ命令と同じ方法で発生しますが、DBG_INSTR_REFを使用します。変数の値は、命令番号とオペランド番号のペアで識別されます。以下の例を参照してください。

$rbp = MOV64ri 0, debug-instr-number 1, debug-location !12
DBG_INSTR_REF !123, !DIExpression(DW_OP_LLVM_arg, 0), dbg-instr-ref(1, 0), debug-location !456

命令番号は、オプションのdebug-locationの付加の前に、オプションのdebug-instr-number付加を使用してマシン命令に直接添付されます。上記のコードで$rbpで定義された値は、ペア<1, 0>で識別されます。

上記のDBG_INSTR_REFの3番目のオペランドは、命令とオペランド番号<1, 0>を記録し、MOV64riによって定義された値を識別します。DBG_INSTR_REFの最初の2つのオペランドはDBG_VALUE_LISTと同じであり、DBG_INSTR_REFの位置は、変数が同じように指定された値を取る場所を記録します。

これらの構成要素の使用方法に関する詳細は、デバッグ情報のための命令参照を参照してください。関連ドキュメントとして、LLVMを用いたソースレベルデバッグおよびデバッグ情報の更新方法：LLVMパス作成者向けガイドも役立つ場合があります。