- 間違ってるのは自分だ
- 間違ってるのは自分だ
- 間違ってるのは自分だ
LLVM使ったら負けかなと思っている
適度になんかいい感じにレジスタ割り当てと命令スケジューリングをしてくれる仕組みが欲しくなってきた。
いや、まあ、本当に欲しいかというと、まだちょっとどうしたいか決まってないので、実はいらない可能性もあるのだが…
それはいいとして、最近はそういう用途にはLLVMを使うというのが主流になってきている。が、個人的にはLLVMを使うのってどうなんだろうと思う。
LLVMで表現できるものは大抵Cでも表現できて、Cで表現できるものにコンパイルするなら、言語を作る必要は無くてコンパイラもいらなくて、最初からCで書けばいいんではないかというような。このへんは、僕がもはやプログラミング言語の文法について何の感動も持たなくなってしまったからだと思うが…
あと宗教上の理由によりApple製品は使いたくないというのが大きい。もはやどうでもいい理由だった。
というような感じで、コンパイラを作るときには、「LLVMでは表現できないものを作ろう」という制約が増えたという話である。(そうだっけ？)
本題とは関係無いが、Cで表現できないがLLVMで表現できるものをメモ書き程度に列挙しておくと…
- シフトの符号の扱いがちゃんと決まってる。(と言っても、今後メンテされるという意味で実質LLVM使うとARMとx86に縛られるので意味あるのかというとよくわからんが)
- 除算の符号の扱いがちゃんと決まっている。(と言っても略)
- シンボルのvisibilityがCより細かく指定できる
- bitcast
- ローテート…っておい、無いんかよ…こうしてローテートできるC言語を作るという俺の壮大な夢は崩れ去ったのだった
こんなもんか…まとめると、「DLLとかsoになった時にシンボルがチラリズムしたら困って、シフトと除算の符号の扱いがクリティカルであって、浮動小数値をIEEE1394ビット列として扱いたい言語」を作るときには、LLVMが非常に活躍するということがわかる。
あとはGCCのattributeでも解決する問題かなーという気がする。あ…visibilityもattributeで解決するよな…まあ、細かいことは気にしないで欲しい。
このへんに関しては、どうせARMとx86以外で使うことは無いんだから、ARMとx86に限定してなんかしたらよいのに、と、思う。具体的にどうしたらいいかは知らない。レジスタを15個にしたりとかですかね…嬉しいか？それ…
さて、このへんを踏まえて(踏まえてないが)LLVMでは表現できない言語を考えると
- 効率良いコルーチンライブラリが作れる(=関数のスタックサイズが取得できる)
- 効率良い継続ができる…てよくわからんが、必要になるまでスタックのコピーを控えるとかすると、なんかバックエンドなんとかしないといけないんではないかな…スタックの移動に耐えられるとか…
- AccurateGC,コンパクション…あれ、なんかドキュメント見るとAccurate GCの作りかたとかあるな…ぱっと見る限りプロトコルが決まってるだけのように見えるが…というかバックエンドの問題というよりフロントエンドの問題という気がするな。GHCは実現してるわけだし
- Intrinsicsを拡張できる。それなんてasm文？まあ、asm文はパイプライン構成無視するので、パイプライン構成まで記述できるasm文。ユーザにまでパイプライン構成を露出させるのん？欲しいか？それ…。まあ、欲しい場面は今まで人生で3回くらいあった気がする。
なんかGHCができてるんだから、ほとんどフロントエンドの問題だろ、という気がしてきたな。Intrinsicsは…x86だとパイプラインはあまりよくわからないので欲しいという気はしない。
とくに結論とかはない。
あと最近はコンパイラ書きたいときはバックエンドまで書きたい気分なことが多い(といってもそこまで到達するまえに飽きてやめてるが…)のでLLVMは必要無いという個人的な事情もある。ここで、「適度になんかいい感じにレジスタ割り当てと命令スケジューリングをしてくれる仕組みが欲しくなってきた」という前提条件がすでにおかしいのだった。
左目まぶたがめっちゃピクピクする
3日目くらい。
ストレスとか目の疲れとかなのか…明日はコンピュータ見ないでゆっくりしよう。
