2010-3-14[日] winの LLVM-Clang でコンパイル.
Clangで、なんとか、コンパイルできた。
(前日冒頭のつづき)
単純なhello.cで#include <stdio.h>だけなら、実はそのまま出来てた。
ただ、3/12のテストルーチンをコンパイルするとヘッダ関係でいろいろ不具合出た。
コンパイル出来た llvm,Clang のソースは llvm rev.98447、clang rev.98448のもの(結構頻繁に更新されてるよう)で、vs2008sp1 にて release の ALL_BUILD して生成.
まず、_WIN32等が設定されてたのは まさに Clangのソース内で設定されていた。
win環境なら _WIN32 定義してて、また、VC環境だと
VCのinclude等のパス設定するような処理があった.
(VCでコンパイルしたから呼ばれるのかVCがinstall済みだからよばれるのかは
よくわかってないけど).
でもってmingw関係も定義されてる雰囲気だった(mingwやgccを詐称してるよう).
VC関係は邪魔なので -nostdinc 指定してデフォルトのincludeパスを見に行かないようにし、
引数で llvm-gcc-4.2 の環境を流用して設定するようにした。
(別に llvmのでなく普通の(最近のバージョンの)mingwの環境でも大丈夫そう)
だいたい
clang.exe -nostdinc -Dwint_t=wchar_t -D__declspec=__declspec -Ix:/llvm/bin/lib/clang/1.1/include -Ix:/llvm-gcc-4.2/include -Ix:/llvm-gcc-4.2/lib/gcc/i386-mingw32/4.2.1/include -O2 -o test.exe test.c
といった感じにコンパイル. +こまごま修正.
- windows.h を受け付けてくれるが wint_t が未設定だったみたいで -Dwint_t=wchar_t で誤魔化した.
- time.hをincludeしたときは、__MINGW_IMPORTが未定義扱いだったので -D__declspec=__declspec を定義して誤魔化した.
- inline関数だった箇所がリンク時に未定義だって怒られたので、static inline に修正した(C++じゃなくてCなんだから static inline じゃないとマズイのだろうな).
- ctype.h をincludeしたら_imp____mb_cur_max_dll等で怒られ、とりえあず ctype.h を使わないようにして逃げた.
ヘマして何か設定が足りてないだけかもしれないが、まだ、ちょっと面倒な状況かも、で。
テストの実行結果は以下の通り。
(最適化オプションは-O2にしたけど妥当かどうかは未考慮)
コンパイラ | Bilinear 拡大(ミリ秒) | 安易 インタプリタ(秒) | quick sort(μ秒) | QSORT(μ秒) | Dhrystone/sec | Whetstone (MWIPS) |
LLVM-clang | 199.9 | 27.9 | 15225 | 67820 | 12841916 | 1478.956 |
他の結果はこっちみて...
結構いい感じ。
このテストだと、VCの次くらい
…gccよりよかったり悪かったりがあるので、類似物じゃないよな。
(安易インタプリタはctype.h関係を手書きマクロに置き換えたので若干条件違うことになるが→結局、他も計測しなおした)
LLVM-gcc は、dmc に対する gdc のようなものに思ってたのだけれど、どうも、測定結果を思い直すと(llvm用コードでなく)ネイティブコード生成時はただのgcc(4.2)なのかも。
追記: やっぱりマ抜けていた。--emit-llvm を指定しないとただのgccかも. --emit-llvm でllvmなコードを一旦はいてからx86向けを作る、みたい. (コンパイル手順はこっちに, 結果はこっちに追記)
で、clang も -emit-llvm 付で生成すれば同様にさらにオプティマイズできるよう。
ただ、手もとの環境で作ると、生成した.exeはハングするので、ちと残念な状態。
(ハングする前に計測結果のでたモノをみるかぎり llvm-gccと同様に早くなってた)
4/23追記: 最近のclang(1.5 trunk 102038)で試したら修正されてるようで動作。(試したのはbilinearのだけだが、さらに速く(97)なっている感じ)