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/secWhetstone (MWIPS)
LLVM-clang 199.927.91522567820128419161478.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)なっている感じ)