A —6-1

2019 年

電子情報通信学会総合大会

ミュータント生成に基づ< LLVM バックエンドの最適化性能テストにおけるェラ一判定の強化

EnhancedErrorDetectioninPerformanceTestofL L V MBackendBasedonMutantGeneration

神田諭志 1

石浦菜岐佐 1

西村啓成 2

福井昭也 2

SatoshiKanda

N agisaIshiura

MasananNishimura

AkiyaFukui

1 関西学院大学理工学部
SchoolofScienceandTechnology,KwanseiGakuinUniversity
2 ルネサスエレクト口ニクス株式会社
RenesasElectronicsCorporation1

test.11 (• mutant.11)
1 define voi
dｩfoo(i8 %al,i32 %a2, i3 2• %a4)nounwind,2 bb:;CHECK‑LABEL: foo:3;CHECK‑NOT: testl
45;CHECK: testb
6%ti ‑zext i
8 %a1 to i
3
27%t2 ‑and i
32 %ti,28%t3 ‑add i
32 %t2, 4096
• %cvt1‑zext i
32%t3 to i128
10%t4 ‑add i
32 %t3, 1 • %cvt2‑add i128%cv
t
1,111• %t4 ‑trunc i128%cvt2to i32
12%c1 ‑xor 1
32 %t4,4097
13知2 = and i
32 1/.
cl,1/.
a2
14知3 = icmpne i
32 %c2,015知1 = xor i
32 1/.t
4,1%v2 = trunc i321/,v
lto i81617• %cvt3= zext i8%v2to i64%v3~a dd i81/.
v
2,2 • %cvt4~add
i64%cvt3,2
18•%cvt5~trunc i64 1/.
cvt
4to i32
19• %v3~trnn
c i32%
cvt5 to i
8
20
21%t5 = sel
ect i11/.c3,i
8 %v3,i8undef%t6~zexti81/.t5 to i
32
2223
store i32 %t6 i 32• %a4
test.s
mu
ta
nt.s
1roo:
1roo:
2ItB
BltO:
2IIBB1
10:3 andl$2,1/.
edi
3 andl$2,%edi4 orl$4097, 1/.
edi4
5 a.
ndl%edi,%esi
56 shrl%esi
67 testb%sil,%sil
7 testl%esi, %edi.
LB
BO̲l
•
.
LB
BO̲
l
8 j
ne
8 jne
9I
tB
Blt
2:
9I
IB
B1
12:.
L
B
B
0
̲
3.
LB
B
0
̲3
10
jmp
10
jmp
1
1 .
LBBO̲
l:
11.
LBBO̲l:12xorl$1,1/.
edi12
13addb$2, %dil
13addl$2,%edi14 .
LEBO ー3:
14.
LBBO̲
3:
15
movzbl %dil,'l.
eax
15movzbl %dil, %eax
16movl%eax ('l.rdx)
16movl%eax (%rdx)

はじめにコンパイラ基盤 LLVM [1] では，機械依存のバックエンド (LLC) を開発すれば新しいプロセッサ用のコンパイラを作成できるが，その際にはバックエンドのテストが重要となる．文献 [2] では LLC に対するテストプログラムからミュータントを生成することによってテストを強化する手法を提案している．この手法では，生成されるアセンプリのコスト比較によ り エラ一判定を行っているが，生成される命令の型等の微妙な相違は検出できなかった．本稿では， LLVM のテス トス イートで用いられている命令パターンの検査を併用することによってエラ一判定を強化する手法を提案する．

,2

LLVM バックエンドの最適化性能テスト
文献 [2] の テス ト手法では， LLVM アセンブリで書かれた LLC の既存テストプログラムに対し，計算結果を変化させない（従って LLC の最適化処理で削除される）ような書き換え（変異操作）を行って新たなテストプログラム（変異体）を得， LLC が生成するコードに差異が生じないかどうかを検査する変異操作は，不要命令の挿入，死亡コードの挿入，演算型の拡張 (8bit 加算の 32bit 加算への変換等），演算の増強（シフトの乗算への変換等）等である．生成されるコードの比較は，命令に定義した重みの和に埜づいて行われ，変異操作がコード全体の性能を低下させればそれを検出できるが，個々の命令のオペランド長等の細かい差異は検出できない．ー方， LLVMのテストスイートでは，テストプログラムから生成されるべき／生成されてはならない命令のパターンを記述し，それを検査している．個々の命令のアドレス指定方式やデータ型まで検査できるが，想定しない命令が生成されてコード品質が低下することは検出できない．

図 1

生成さ れるコ ードの差分を検出 した ミュータント

件 でエラ一を検出し た ．図 1 の test.II は元のテストプ ログラムであり，‘‘→”の右側が挿入した変異である. 4,..,5 行
目では test! ではなく testb が生成さ れるべきことを 記述している. test.s と mutant.s は ， それぞれ test.II とその変異体から 生成されたアセン プ リで ある変異 によって 7 行目で testb が生成できなくなったことが検出されているが，これは従来法で は検出できな かったものである．ー方で，全体としては mutant.s のほうが簡潔であり，LLC の最適化処理の改善を考える上で参考になるテス
卜ケ 一スと考えられる．

3 パターンマッチングによるェラ一判定の併用
本稿の手法では，文献 [2] の工ラ一判定において LLVM
テストスイートのパターンマッチングによる検査を併用
する. LLC が生成するコードは基本的には変異操作の馳響を受けないので，検査用のパターン記述は元のテストプログラムのものをそのまま利用できる．た だ し一部の変異操作は覗き穴最適化に影響を与え，多くの変異体がこの検査でエラーとなることがあるため，そのよ うな変異操作は除外する必要がある．具体的な例としては，死亡コードの挿入は変異操作から除外する．

むすび
本稿では，二つの 判定基準 を併用することによっ て
LLVM バッ クエン ドのテストを強化する手法を提案した ．ミューテーション操作のバリ エーションを増加さ せることが今後の課題 と してあげ ら れる．

5

4 実験結果

参考文献

提案手法に基づくテストシステムを， [2] を拡張することにより実装した．対象とした LLVM のバージョン[1] https://llvm.org/.

は 4.0.0 である.

[2] 田中 ， 石浦，西村，福井： "LLVM バックエンドの殻適化性能
テストのミュータント生成，”信学技報， VLD2017-88 (Jan.

LLVM テストスイー トの 2012-08-07-2018).

CmpISelBug から生成 した 110,000 件の変異体のう ち 34

2019/~{/19‑ 22 束泉・

55（基礎・境界 /NOLTA 講演論文集）

Copyright@ 2019IEICE