2013-06-22
clang+llvmでさりげなくすごいコードが生成されていた話。
先日llvm 3.3がリリースされました。aarch64(arm 64bit)のコードが生成できるようになったということなので、ソースからビルドして遊んでいたのですが、さりげなく凄く最適化されたコードが生成されているのに気がつきました。aarch64だと今は実行して確認できる環境が手元に無いので、普通のarmv7-aで同じことを試しました。
ここで使ったコードとその結果はgistに貼りました。
https://gist.github.com/tetsu-koba/5835724
ソースコード
int sum(int x) { int sum = 0; int i; for (i = 1; i <= x; i++) { sum += i; } return sum; }
1からnまでの総和を求める関数です。1から100までの総和が5050なのはガウス少年の逸話で有名ですね。
gcc 4.8.1での生成コード
sum: cmp r0, #0 ble .L4 adds r2, r0, #1 movs r3, #1 movs r0, #0 .L3: add r0, r0, r3 adds r3, r3, #1 cmp r3, r2 bne .L3 bx lr .L4: movs r0, #0 bx lr
最適化 -Oをつけてコンパイルしています。(-O3にしても特に変化はありません。)
ソースコードに忠実にループを回しています。これが普通のコードだと思っていました。llvmのコードを見るまでは。
clang+llvm 3.3 での生成コード
sum: mov r1, #0 cmp r0, #1 blt .LBB0_2 sub r1, r0, #2 sub r2, r0, #1 umull r1, r2, r2, r1 and r2, r2, #1 lsrs r2, r2, #1 rrx r1, r1 add r0, r1, r0, lsl #1 sub r1, r0, #1 .LBB0_2: mov r0, r1 bx lr
あれ?umullは乗算命令かな。よく見るとループしてないぞ!
1からnの総和はn回加算しなくても、1/2 * n * (n + 1) で求められることは知識としては知っていますが、llvmはそれと似たようなことをしています。しかし微妙に違う。これが正しいのかどうかぱっとみて判断がつきません。(これに関しては別エントリで深堀する予定。)
高速化のために元のソースを手でアセンブラ化するとしてもここまでのコードは即座には書けませんね。私ならコンパイラにお任せします。
さらに以下のコードを追加してみました。
#include <stdio.h> int main() { int n; n = 100; printf("sum(%d) = %d\n", n, sum(n)); }
そして、その部分の生成コードは
main: push {r11, lr} movw r0, :lower16:.L.str mov r1, #100 movt r0, :upper16:.L.str movw r2, #5050 mov r11, sp bl printf mov r0, #0 pop {r11, pc}
これは一本取られた!
sum(100)=5050なのはコンパイルした時点でわかっているので、もうsum関数を呼ばずに定数で5050をprintfに渡しています。
ちなみにgcc 4.8.1だと
main: movs r3, #1 movs r2, #0 .L9: add r2, r2, r3 adds r3, r3, #1 cmp r3, #101 bne .L9 movw r0, #:lower16:.LC0 movs r1, #100 movt r0, #:upper16:.LC0 b printf
sum関数がここにインライン展開されて、定数100が埋め込まれていますが、いぜんとして100回ループしています。
まとめ
この関数の一例について言えば、gccの最適化だとループの回数は変わりませんが、clang+llvmでは徹底的のループを除去しようとします。ループの回数が大きくなるとその実行時間の差は如実に現れるはずです。llvmすごい。(なお、この最適化がllvm 3.3からなのか、それ以前からそうなのかは調べていません。)
私自身はコンパイラの中身についてそれなりに知識があるので、このような最適化が可能であることは知っていたのですが、現状のclang + llvmでコンパイルオプションに-Oをひとつ追加するだけでここまでやってくれるとは驚きでした。
さらに思ったこと
llvmでこのような最適化ができたのは、このsum関数が「純粋な関数」であり、与えられた引数によってのみ関数値が計算でき、それ以外の副作用の影響を受けないし与えないからです。C言語ではうっかりすると副作用のあるコードを混ぜてしまうことが簡単にできてしまい、(例えば、ループの中でグローバル変数やポインタを参照するなど。)そうすると最適化が効かなくなってしまいます。
これからのコードを書く者の技量として、どう書くとどう最適化が効くか、いかに最適化を邪魔しないようにコードを書くかということが問われるのかなと思いました。あるいは、コンパイラの最適化を邪魔しにくいような言語仕様の言語を習得してそれを使うか。コンパイラの最適化を邪魔しにくい言語のひとつとしては関数型言語がありますね。
- Twitter / @tetsu_koba
- Twitter / @kumadasu
- Twitter / @monamour555
- Twitter / @kimuchi1203
- Twitter / @suikan_blackfin
- Twitter / @NSaitoNmiri
- Twitter / @yrntrlmnmnt
- Twitter / @qbd
- Twitter / @sabakawa
- Twitter / @sona_tar
- Twitter / @nonakap
- Twitter / @bleuscr
- Twitter / @kumar8600
- Twitter / @honyoka
- Twitter / @u_akihiro
- Twitter / @wdko
- Twitter / @Fantom_JAC
- Twitter / @yikemac
- Twitter / @__machia__
- Twitter / @toshinarin
- Twitter / @shkoga
- Twitter / @OsamuHB
- Twitter / @asatetsu
- Twitter / @a4lg
- Twitter / @func_hs
- Twitter / @mikoto2000
- Twitter / @twittarsan
- Twitter / @shelarcy
- Twitter / @fd0
- Twitter / @ShintaroHosoai
- Twitter / @Constellation
- Twitter / @44attack
- Twitter / @h_sakurai
- Twitter / @mihchang
- Twitter / @itchyny
- Twitter / @pettarou2
- Twitter / @ishi_kuro
- Twitter / @ritzberry
- Twitter / @kz_kazuki
- Twitter / @risuoku
- Twitter / @yohhoy
- Twitter / @cobodo
- Twitter / @__MASAKI__
- Twitter / @oTheRwoRldy
- Twitter / @ntddk
- Twitter / @kariya_mitsuru
- Twitter / @saka1_p
- Twitter / @suruga__
- 515 http://b.hatena.ne.jp/
- 304 http://t.co/eb1NGaQMBQ
- 255 http://b.hatena.ne.jp/hotentry/it
- 247 http://b.hatena.ne.jp/hotentry
- 184 http://t.co/t6aDf8eKeV
- 138 http://cloud.feedly.com/
- 124 http://t.co/LmLr6uDAFk
- 112 http://reader.livedoor.com/reader/
- 104 http://b.hatena.ne.jp/entry/d.hatena.ne.jp/embedded/20130622/p1
- 102 http://www.feedly.com/home
- 2013-06-16 J 6/38 15%
- 2013-06-16 偏った言語信者の垂れ流し 5/63 7%