11/07/27 06:07:11.36
レジスタサイズ整数とかアドレスサイズ整数とかが無いからクロスプラットフォームにしてもいまいち使い辛いんでないかい
382:デフォルトの名無しさん
11/07/27 10:27:17.80
llvm ってオレオレ VM を作るためのフレームワークとかツールキットっていう位置づけで出てきたんでしょ。
最適化は「将来的には夢が広がりんぐ」って形で最初からあったけど、llvmが最適化目的のプロジェクトというわけじゃないよ。
383:デフォルトの名無しさん
11/07/27 12:05:18.49
>>381
クロスプラットフォームにはない方がむしろいい。
384:デフォルトの名無しさん
11/07/27 14:36:21.79
>>383
sizeofってどうなんの？
あり得ないと思うけど、
bitcodeの実行先で決定?
385:デフォルトの名無しさん
11/07/27 17:38:13.98
>>383
int変数一個をbitcodeにするだけで32ビットと64ビットで互換性なくなるんだぜ
iregとか書きたいよ
386:デフォルトの名無しさん
11/07/27 23:12:36.32
>>384
それはfrontendが決めること。
llvmはターゲットに応じて適切な機械語に変えるだけ。
387:デフォルトの名無しさん
11/07/27 23:27:54.50
じゃあbitcode上のレジスタサイズは一応決まってんだ。
少なくともintとlongが異なるのにそれぞれに割り当てたレジスタが
同じサイズになったりしたら困るもんね。
388:デフォルトの名無しさん
11/07/28 00:16:28.83
bitcodeのレジスタサイズ？
URLﾘﾝｸ(llvm.org)
みながら
URLﾘﾝｸ(llvm.org)
でコンパイル結果みて
URLﾘﾝｸ(llvm.org)
あたり読めば疑問は解決すると思う
389:デフォルトの名無しさん
11/07/28 00:46:02.72
なるほど。そもそもレジスタサイズの話は中間言語一般の話でLLVMとは関係なかったな。
390:デフォルトの名無しさん
11/07/28 01:05:25.21
インラインアセンブラ使ったコードコンパイルしてみた。
call void asm sideeffect "mov %eax,%ebx", "~{dirflag},~{fpsr},~{flags}"() nounwind, !srcloc !0
カプセル化されるのか面白いな。
391:デフォルトの名無しさん
11/07/28 01:32:37.89
>>386
inttoptrとかどーするのよ
392:デフォルトの名無しさん
11/07/28 01:58:32.60
揚げ足だけど、整数からポインターへの変換が必要なようなアホコードは捨てろよ。
Memory Maped I/O ぐらいでしか必要ないでしょ。
393:デフォルトの名無しさん
11/07/28 08:04:09.54
整数とアドレス値の境目のなさがコンピュータの醍醐味でしょ
394:デフォルトの名無しさん
11/07/28 11:58:27.05
>>393
そこを設計でうまく切り分けて取り扱うのがプログラマーじゃね？
395:デフォルトの名無しさん
11/07/28 12:25:24.19
LLVM CodeGen はともかく、Analysis/Transformations(いわゆるopt)は
TargetData すなわち語長とかアライメントにすごく依存している。
TargetData を取り去って最適化をかけようとしてもロクな結果が得られない。
sizeof, offsetof とかは、バックエンド的には gep NULL / ptrtoint を吐いとけば十分で
あとはInstCombineとかConstantPropあたりがTargetDataに即した数字にしてくれる。
396:デフォルトの名無しさん
11/07/28 20:31:23.87
int f(int n) {
int a[n];
return sizeof(a)/sizeof(int);
}
397:デフォルトの名無しさん
11/07/28 20:51:03.14
>>395
char buf[sizeof(struct t)] とかやることを考えたら、結局フロントエンドでも把握してないといけないわけで、
フロントエンドとバックエンドが別々にサイズ足してアライメント考慮して……ってやるのはバグの元だし
やっぱりクロスプラットフォーム投げ捨ててるし、もうちょい上手い方法が欲しいけどなあ……
398:デフォルトの名無しさん
11/07/28 21:17:24.22
フロントエンドが決めずに誰が決めるんだよw
CやC++の仕様(intのサイズは実装任せ)と
処理系の実装の話を混同してないか?
処理系はいつもサイズを決めてる。
アラインメントも決めてる。
「決まらない」のはあるソースに対して、
処理系を変えた場合。
399:デフォルトの名無しさん
11/07/28 21:22:37.75
フロントエンドがstruct {char x; int y}のサイズを計算した値と
LLVM側が{ i8, i32 }のサイズを計算した値が一致する保証はないよね、怖いね、って話だよ
400:デフォルトの名無しさん
11/07/28 21:37:48.70
合うように{ i32, i32 }にしてるっしょ?
401:デフォルトの名無しさん
11/07/28 23:22:35.15
春先まで {[8 x i8]} だったわけだがw
TDの扱いについては clang と llvm でコンセンサスはとれてる。