5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【最速へ】LowLevelVirtualMachine【LLVM】

1 :デフォルトの名無しさん:2008/05/23(金) 22:00:55
Native用言語向け仮想機械、LLVM(低水準仮想機械)について語りませう。
いくら探しても無いので立てました。

本家: ttp://llvm.org/
参照: ttp://ja.wikipedia.org/wiki/Low_Level_Virtual_Machine



2 :デフォルトの名無しさん:2008/05/23(金) 22:08:39
まだ早い
終了

3 :1:2008/05/23(金) 22:15:09
とりあえずLinuxにて素数計算を書いてコンパイルした感想。
現時点ではまだ通常のバイナリと同じか寧ろ遅いようです。
しかも、一つの生成した実行ファイルにVMと本体が同居している
せいかファイルサイズが異様にデカい…。
しばらくは様子見と言った感じですかね。生ぬるく見守っていきましょう。

4 :デフォルトの名無しさん:2008/05/23(金) 22:40:23
これって何ができるの?
汎用的なjvm?

5 :デフォルトの名無しさん:2008/05/23(金) 22:41:09
LLVM インタープリタは別にはやくないべ
llvm-gcc で普通に native code にコンパイルしたら?
OS X 上で 32 bit モードだと llvm-gcc のほうが普通の gcc より全然早かったけど。
http://accc.riken.jp/HPC/HimenoBMT/index.html
でやりました。

6 :デフォルトの名無しさん:2008/05/23(金) 22:47:38
CやC++やらFortranとか、もともとNative向けに作られている言語向けのVMで、
JavaVMと同じく実行時の最適化を行う。おまけに実行時に条件分岐が
どちらに飛びやすいか、どの命令が使われやすいかなどProfileを取ってバイナリ
自身を書き換え、使えば使うほど勝手に速度を増すらしい。

7 :デフォルトの名無しさん:2008/05/23(金) 23:34:03
LLVMの実用例ってどんなのあるんだろうな

AppleがLeopardでグラフィックス層に採用したが、
GMA950なMacではBlenderが意味不明なほど重くなってる
(Tiger起動時は無問題)
利点がさっぱりわからん

8 :デフォルトの名無しさん:2008/05/23(金) 23:43:01
>>7
http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/771003390931

Apple はこれの為にわざわざ LLVM の ARM バックエンドを作ったらしいね

http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-January/007813.html

こういう感じで開発機と本番機のアーキテクチャが違う場合は恩恵が大きい
というか、ナイスアイデアだと思った

9 :デフォルトの名無しさん:2008/05/23(金) 23:56:48
あー、仮想化としての意味合いが強いのか。なるほどthx

10 :デフォルトの名無しさん:2008/05/24(土) 00:27:36
OpenGLのJITをLLVMのJITに置き換えただけでは?

11 :1:2008/05/24(土) 01:27:32
とりあえず50万までの素数計算したときの計測値を貼ってみる。それぞれ10回。
比較対象はLLVM-GCC(ver 2.1)とGCC(ver 4.3)。
対象言語はC++、基本比較回数41,539回。
一応、中枢処理はinline関数版とマクロ版のを用意。
check:41539,score:755 clock/ms

LLVM-GCC版
inline関数 :マクロ
 4240  :1315
 4280  :1265
 4190  :1245
 4200  :1235
 4150  :1255
 4210  :1355
 4280  :1255
 4220  :1305
 5    :1275//恐らく何らかのミス
 4190  :1185

通常GCC版
inline関数..:マクロ
 755  .:1255
 825  .:1165
 705  .:1125
 695  .:1145
 695  .:1095
 675  .:1135
 635  .:1145
 855  .:1285
 995  .:1255
 845  .:1175
Clock関数で測定したんで、値が低いほど早いです。ソースはやや長いので書き込み不可。

12 :1:2008/05/24(土) 01:42:09
>>11
>check:41539,score:755 clock/ms
はゴミなんで気にしないでください。

13 :デフォルトの名無しさん:2008/05/24(土) 03:49:25
(llvm-)gcc の最適化オプションは?

14 :1:2008/05/24(土) 08:10:25
>>13
共に-O3です。
inline版はtemplateを多用して
いたんですが、コンパイラ的に
inline展開した中間コードを
吐くのは苦手なのかな?



15 :デフォルトの名無しさん:2008/05/24(土) 08:34:39
う〜ん、姫野ベンチでは LLVM のほうがはやかったので、1さんがどんなソースなのか興味ありますね。どっかのアプロダに置いてくれませんか?

16 :1:2008/05/24(土) 12:12:19
>>15
元々ベンチ用コードじゃないんで
読みづらいかもしれませんが、
時間があれば夜上げておきますよ。
あまりアップローダ使わないんで、
よろしければ、良さげなところを
教えて下さいな。

17 :デフォルトの名無しさん:2008/05/24(土) 12:56:49
ttp://codepad.org/ とかじゃダメ?


18 :1:2008/05/24(土) 22:43:54
http://codepad.org/aLVS4Jld
こんなんでいいのかな?

いくつか、自作ヘッダincludeしてあるけど、
処理その物とは直接関係なかったから上げてはないよ。

あと、正直ベンチ計測したのは2週間くらい前でLinux用のコードを
どこにやったか見当たらなかったんだ。ゴメン。

だから代わりに、その後、VCの比較用にWindows向けに弄ったやつを
載せさせてもらうよ。基本的には変わらないはずだから許してね。
(もしかしたら、バグ取りの途中のヤツかも…)

それとコードはかなり汚いし、アホだけど、一応処理系毎の最適化を
調べる目的で書いたんだ。その辺に関してはスルーしてね。

19 :デフォルトの名無しさん:2008/05/25(日) 01:54:14
そのコードで inline 版とマクロ版がそんなに違うのはやっぱり何かが変なんではないかと思うな ... というか inline/マクロのちがいというより std::vector<int> と int[] の違いなのか。

20 :デフォルトの名無しさん:2008/05/25(日) 12:26:55
過去スレ
http://pc11.2ch.net/test/read.cgi/tech/1166508605/

21 :1:2008/05/25(日) 19:27:01
>>19
今回は、配列版だけしか使ってないよ。
そういえば、VCでVectorと配列で測ったら
Vector版の方が早かったよ。スレ違いでは有るけど
何でだろうね。

(以降は名無しに戻ります)

22 :デフォルトの名無しさん:2008/05/26(月) 00:02:56
>>21
あげてくれたソースコードではコマンドラインオプションで「マクロ」を選ぶと int[] になってて、「インライン」だと vector<int> になってたけど ???

23 :デフォルトの名無しさん:2008/05/26(月) 02:55:49
>>22
ホント?コード上はoptionの3bit目を基準に書いてたんだけど、
optionの指定も分岐も問題なさそうだよ?
環境依存か何か書いたかなぁ。

24 :デフォルトの名無しさん:2008/05/26(月) 03:35:11
あ、なるほど、読み間違ってました、失礼。

25 :デフォルトの名無しさん:2008/05/26(月) 08:18:39
#include <stdio.h>
#define TARGET 1000000
int primes[TARGET];

int main(){
int n=0;
int i;
primes[n++]=2;
for(i=3;i<TARGET;i++){
int k;
for(k=0;k<n;k++){
if((i%primes[k])==0) break;
}
if(k==n){
primes[n++]=i;
}
}
printf("total: %d primes¥n",n);
return 0;
}
だけでやってみました。Core Duo 2GHz です。
llvm-gcc-4.2 , gcc-4.2 で -O4 でコンパイルして time ./a.out で計っただけです。結果は llvm-gcc が 21.5 秒、gcc が 23.3 秒、まああんまり変わらないですが。

やっぱ 1 さんのは inline 展開がされてないんではないかと気になりますね。

26 :デフォルトの名無しさん:2008/05/26(月) 19:59:04
なるほどね。もしかして、GCCだと__attribute__でinline指定しないと
ダメなのかな?あとで、>>25さんのコードも含めてやってみるよ。
ところで、面白い記事があったから貼っとくね。
http://lucille.atso-net.jp/blog/?p=430
どうやら、物によっては30%も加速するんだって。どんなコードだろ?

27 :デフォルトの名無しさん:2008/05/26(月) 23:48:53
>>26
僕はその記事をまえにみたときに自分で姫野ベンチやってみたんですが、
x86 ではたしかにかなり加速しましたよ。なぜか x86-64 ではあまり加速しなかったんですが。1 さんの Linux box は もしかして 64 bit ?

28 :デフォルトの名無しさん:2008/05/27(火) 00:17:03
>>27
 いや、PenMなんだ。もしかしたら、アーキティクチャが影響したのかも
とも思ってたんだけどね。
浮動少数より整数演算が強いってことはSSEとか最適化かかると
逆に弱いかもしれないし。(ASMまで考えて無いからいい加減…。
今は、時間が無いから時間が空いたら色々試して報告してみるよ。

29 :デフォルトの名無しさん:2008/05/28(水) 23:35:56
あれ、Linux(Fedora)の標準リポジトリにもう入ってる?

30 :デフォルトの名無しさん:2008/06/14(土) 19:32:38
MacのOpenCLもLLVM使うらしいね。
http://lucille.atso-net.jp/blog/?p=526

31 :デフォルトの名無しさん:2008/06/15(日) 00:19:02
ttp://www.ottimo.co.jp/koike/
>OpneCLは大学や研究所関係者が泣いて喜ぶかも(笑)そしてリンク時のオプティマイズとは恐れ入りました!

32 :デフォルトの名無しさん:2008/06/15(日) 00:24:24
注目しているのはむしろ Grand Central だと思うけどな

33 :デフォルトの名無しさん:2008/07/01(火) 20:42:39
Xlibとか、Win32APIとか、埋め込みSQLなんかの
決まりきった設定系処理なんかにも効き目あるんだろうか?

34 :デフォルトの名無しさん:2008/07/06(日) 15:21:11
ttp://clang.llvm.org/StaticAnalysis.html
objcスレ向きか?

35 :デフォルトの名無しさん:2008/07/30(水) 23:57:06
しばらく前だけど、LLVM2.3のベンチマークが載っていた。

http://journal.mycom.co.jp/news/2008/07/07/016/index.html
http://www.stefankrause.net/wp/?p=9

この結果はlliを使っているようなので、
llcを使ってネイティブコンパイルした場合の結果が
気になるところだ。

LLVM2.2のベンチマークはこちら。
http://lucille.atso-net.jp/blog/?p=430

それから、LLVMの勉強会が開かれるらしい。
場所は恵比寿なので、東京近郊の人は行ってみれ。

http://groups.google.co.jp/group/llvm_study/web/%E7%AC%AC%E4%B8%80%E5%9B%9E+llvm+%E5%8B%89%E5%BC%B7%E4%BC%9A



36 :デフォルトの名無しさん:2008/08/07(木) 21:08:11
ttp://llvm.org/devmtg/2008-08/

37 :デフォルトの名無しさん:2008/08/30(土) 11:05:57
ttp://www.cups.org/articles.php?L562+TNews+P1+Qlpd+ipp
>Removed unused variables and assignments found by the LLVM "clang" tool.
>Added NULL checks recommended by the LLVM "clang" tool.

ttp://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html
>this is a basic idea of Blocks: it is closures for C.
>It lets you pass around units of computation that can be executed later.

38 :デフォルトの名無しさん:2008/10/05(日) 02:11:25
なんだか過疎ってるね
なんかネタない?

39 :デフォルトの名無しさん:2008/10/05(日) 19:14:38
ttp://llvm.org/devmtg/2008-08-23/

40 :デフォルトの名無しさん:2008/10/06(月) 02:35:16
寝る前にベンチでも取ってみようかと、Mingw32/x86のllvm-gccとllvm-ldでgzipコンパイルしたんですけど、
lliで実行すると

ERROR: Program used external function 'close' which could not be resolved!

というエラーが出ます。
ビルドがうまくいってないのかと思い、

#include <stdio.h>
#include <stdlib.h>
int main()
{
FILE *fp;
fp = fopen("out.txt", "w");
if(fp == NULL) { fprintf(stderr, "error: fopen"); exit(1);}
fprintf(fp, "hello world\n");
close(fp);
return 0;
}

みたいなコードで試してみたんですが同じエラーが出ました。
close()をコメントアウトすると動いているようです。
mingw版は外部のライブラリとのリンクはまだうまくできないんですかね?

41 :デフォルトの名無しさん:2008/10/06(月) 02:50:29
fclose

42 :デフォルトの名無しさん:2008/10/06(月) 03:27:27
>>41
ですね・・・失礼しました;;

念のため
int main() { close(0); return 0;}
というコードでも試してみたんですが、やはりリンクはできないようでした。
gzipをfopen(), fclose()を使うように書き換えてみる or gzipはあきらめるなど
また今度試してみようかと思います。

43 :デフォルトの名無しさん:2008/10/06(月) 03:43:02
MinGWはmsvcrt.dllを使っていて、そこではcloseがANSI C標準に入っていないという理由で
_open/_closeという名前になっているのが原因か?
MinGWはろくに使ったことがないけど。

44 :デフォルトの名無しさん:2008/10/06(月) 08:34:03
>>39
第1回勉強会か。英語で紹介されるとカッコいいなw
第2回ってないの?あるなら行きたいんだけど

45 :デフォルトの名無しさん:2008/10/06(月) 17:28:24
>>42
>>43の言うとおり、Win32 CRTでは、ANSI C標準に入っていない関数(UNIXで言うところの
システムコールも含む)は先頭に_をつけた関数名になる。
だから、MinGWでビルドするならすべて名前を変更しなければならない。
たぶんストリーム関数を使うように書き換えるより、open, close, read, writeあたりを
_つきに置き換える方が楽だと思う。

46 :40:2008/10/08(水) 02:35:22
>>43 >>45
ありがとうございます。一部関数を'_'つきに変えたら何とかコンパイルはできました。
ただ挙動がかなりあやしげですが・・・。たとえば引数無しで実行すると反応がなかったり。
一応解凍はできるようになったみたいなんでベンチとってみました。
計測はtimeコマンドでやりました。
結果見るとllvmでいい結果がでてますが、gccでのコンパイル、llvm-gccでのコンパイルともに
完全ではないなので参考までということで。
ちなみに
llvm-2.3(gzip-1.2.4) はgzip-1.2.4をllvm-gccでコンパイルし、lliで実行したものです。
llcでのネイティブへの変換はうまくいきませんでした。
gcc-3.4.4(gzip-1.2.4) はgzip-1.2.4をcygwinのgcc-3.4.4でネイティブバイナリにコンパイルしたものです。
cygwin(gzip-1.3.12) は配布されているcygwinのバイナリです。
==== llvm-2.3(gzip-1.2.4)
user 0m0.031s
user 0m0.031s
user 0m0.015s
user 0m0.000s
user 0m0.015s
==== gcc-3.4.4(gzip-1.2.4)
user 0m5.085s
user 0m5.054s
user 0m5.054s
user 0m5.163s
user 0m4.897s
==== cygwin(gzip-1.3.12)
user 0m4.914s
user 0m5.413s
user 0m5.038s
user 0m5.163s
user 0m5.085s
正しく計測ができていなそうですが、せっかく測ったので。

47 :40:2008/10/08(水) 02:36:36
あと、
gzip-1.2.4をllvmでコンパイルするパッチを
http://codepad.org/doeKoAQi
に、(パッチ当てた後 BUILD.sh を実行すればコンパイルできるはずです)
テストに使用したスクリプトを
http://codepad.org/T4LSsUpK
に、このスクリプトの実行結果を
http://codepad.org/RZyAm3Tb
にはりました。


48 :デフォルトの名無しさん:2008/10/08(水) 09:38:16
gcc も -O3 だけじゃなくて最適化オプションいろいろ調整すれば
もうちょっとはやくなったりするので、何を持って llvm-gcc の速度というか疑問だったりするんですが。

49 :デフォルトの名無しさん:2008/10/10(金) 07:19:30
mingwのllvm-gccとcygwinのgccで比較しちゃダメでしょ。
cygwin gccのバイナリの方がが遅いのは当たり前。

50 :デフォルトの名無しさん:2008/10/10(金) 21:50:25
うお、よく見たらCygwinと比較してるのか。ダメすぎるぞ。
確かにCygwin版ならopen(2)とかclose(2)とかがそのまま使えたかも知れないが、
それはCygwinでそのあたりの関数群をエミュレーションしてるからだ。だからむちゃくちゃ
遅くなる。
llvm-gcc版と全く同一のコードでビルドできるから、MinGW-gccでもう一度やり直し。

51 :デフォルトの名無しさん:2008/12/02(火) 23:03:18
オレ言語コンパイラをllvm対応させるとどんなよいことがありますか?

52 :デフォルトの名無しさん:2008/12/02(火) 23:10:51
Alchemy使ってFlash化できるかもしれない。
いや、俺まだ触ってもいないけど。

53 :デフォルトの名無しさん:2008/12/03(水) 01:27:06
最適化とかを自分でやらなくて済むくらいかな
でもこれはgccでも一緒か。作業的にはC++で書かれてる分LLVMのが楽そうだけど

54 :デフォルトの名無しさん:2008/12/03(水) 07:33:37
いやgccは魔境らしいからLLVMやろうぜ

55 :デフォルトの名無しさん:2008/12/14(日) 02:54:18
一応書いておくと、LLVMの開発系MLは以下で読めるよ。

ttp://lists.cs.uiuc.edu/pipermail/llvmdev/

今月分
ttp://lists.cs.uiuc.edu/pipermail/llvmdev/2008-December/date.html

56 :デフォルトの名無しさん:2008/12/17(水) 18:05:00
clangとLLVMをベースにしたOpenCLの実装が開発中らしい。

http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-December/018913.html

57 :デフォルトの名無しさん:2008/12/27(土) 19:51:36
これWindowsだとどう処理されるの?
一応実行中のバイナリは書き換えできないよね?

58 :デフォルトの名無しさん:2008/12/27(土) 19:57:26
>>57
実際のところ、実行時最適化は Windows 以外でも使われてない。

59 :デフォルトの名無しさん:2008/12/29(月) 09:28:27
やったとしても"バイナリ"を書き換える必要はないだろうけどね

60 :デフォルトの名無しさん:2009/01/13(火) 08:16:38
>>56
clangもLLVMもOpenCLも、Appleが主導してるようなものだからなぁ。
結局は積極的に利用するのはAppleくらいなものじゃないのかね。
LLVM-GCCもiPhoneくらいだろ?実際に使ってるの。

61 :デフォルトの名無しさん:2009/01/13(火) 10:56:42
その実装はAAPLとは全く別でしょ。
最近VMMに買収されたらしいよ。

62 :デフォルトの名無しさん:2009/01/13(火) 14:49:29
>>59
if(a<5&&b<10)break;
ってな条件があって成功しない
確率の方が多い時(ループ中のbreakとか)
実際の利用状況としてa<5は頻繁に成立しまう場合は
if(b<10&&a<5)break;
と書き換えてしまった方が早くならない?
とくにファイルに保存したデータの状況によって
b<10とa<5の成立頻度が変わる場合は便利な気がする。

63 :デフォルトの名無しさん:2009/01/13(火) 21:52:15
それならどのみち分岐予測が効くから違わんのでない?

64 :デフォルトの名無しさん:2009/01/14(水) 08:59:57
>>62
(直前のレスを読んだなら)>>59が言ってる"バイナリ"は、オンメモリの実行コードのことじゃないことはわかっていると思うが…
結局の所、実行ファイルを書き換える必要は無いよな

65 :デフォルトの名無しさん:2009/01/14(水) 13:49:10
そう?実行時に書き換える手間が減るからある程度は効果ありそうに思うけど

66 :デフォルトの名無しさん:2009/01/15(木) 09:33:51
実行ファイルとngenのキャッシュ的なものがごっちゃになってる気がする
独自のJITキャッシュデータの話なら、書き換えできるできないの話にはならないし
実行ファイルそのものを書き換えるという話なら、USBに入れて使えない

67 :デフォルトの名無しさん:2009/02/09(月) 19:39:06
llvm-gcc -emit-llvm -S で吐き出したコードの中に

%val = load i32* getelementptr (%struct.S* @b, i32 0, i32 0)

のような、load 命令の中で getelementptr 命令を使っている行がありました。

LLVM IR にこのような文法があるのでしょうか?
リファレンスマニュアルを見ましたがこの文法が見当たりませんでした。

68 :デフォルトの名無しさん :2009/02/09(月) 23:23:53
llvmを使って新しいカーネル作れないかな?

69 :デフォルトの名無しさん:2009/02/10(火) 18:20:42
LLVM の最適化は自動ベクトル化に対応しているでしょうか?

2つの4次ベクトルの要素をすべて取り出して、対応する要素を加算して、
加算の結果をまたベクトルに戻す処理を書いたのですが、opt -std-compile-opts
で最適化しても1つのベクトル加算に変換されていませんでした。

70 :デフォルトの名無しさん:2009/03/02(月) 14:08:49
>>67
亀レスだけど、ConstantExprのことかな?
マニュアルには載っていないので、ソースコードを読まないと分からない。
ExpressionをConstantとして扱う機能だから、
この場合はgetelementptr命令の返却値をload命令の引数にするという意味。
(ConstantExprの場合は括弧が追加される)

「include/llvm/Constants.h」と「lib/VMCore/Constants.cpp」にある
定義を読み「lib/VMCore/AsmWriter.cpp」でLLVM IRとしては
どんな文字列が出力されるのか確認すれば、分かるようになるかもね。

分からなければ、自分ではConstantExprを使わずに、
別のInstructionに分けて書けばいいと思ふ。
(この場合はgetelementptr命令の返却値を一度変数に代入する)



71 :デフォルトの名無しさん:2009/03/02(月) 14:10:14
第2回勉強会をやるみたいだね。
興味のある人は参加してみては。

http://atnd.org/events/381



72 :デフォルトの名無しさん:2009/03/02(月) 21:56:22
>>71
もう申し込んだよ。楽しみだー。

73 :デフォルトの名無しさん:2009/03/09(月) 19:22:48
HLVMのアルファ版が出たようだ。
コンパイラや言語を自作したい人は、これをベースにすると楽ができるのかも。

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-March/020729.html



74 :デフォルトの名無しさん:2009/03/14(土) 23:26:46
教えてもらいたいんだけど、
LLVMのJITって
lli + *.bcのビットコードの状態じゃないと有効じゃないの?
llcでネイティブなコードした実行ファイルの状態だと
普通のコンパイラがはいたバイナリと同じ?

75 :デフォルトの名無しさん:2009/03/15(日) 20:51:40
そう。
それにデフォルトの状態では特にJITであること生かした動作してない気がする。

76 :デフォルトの名無しさん:2009/03/16(月) 21:27:06
>>75
ありがとう。
llvm-ldで実行ファイルできるじゃん
って思ったら.bcをlliに渡すラッパーだったw

ところで、mingw用のインポートライブラリを
変換する方法ってないんですかね?


77 :デフォルトの名無しさん:2009/03/21(土) 00:11:46
勉強会age
このスレまだ100も行ってないのかyo

78 :デフォルトの名無しさん:2009/03/21(土) 00:45:56
>>73
軽く読んでみた限り思ったよりHighLevelじゃないしあんまりメリットが見えない。
OCamlはかじった程度なんで間違ってたら解説よろしく。

>>77
ユーザーの絶対数少なそうだし。
勉強会の懇親会で食中毒でも起こったら日本のLLVM関係者の1割ぐらい減るんじゃなかろうか。

79 :会場の人:2009/03/21(土) 12:37:18
>>77
もう明日か。
思いのほか人数増えちゃってgkbrしてます。入りきるかなー・・・。
色々不手際あるかと思いますがゴメンナサイ。と、今から誤っておくます。ヒー

電源タップの数がまずもって全然足りてないので、
ノートPC持ってくる人は満充電にしてきてね!

80 :デフォルトの名無しさん:2009/03/21(土) 13:55:22
>>79
電源タップもって行けば会場の電源の容量は足りますか?

81 :会場の人:2009/03/21(土) 15:01:47
電源容量は・・・調べてませんがノートくらいならまかなえると思います。さすがに。
もし火を吹いたら、消火のご協力をお願い致します。w

というか電源タップ持ってきて頂けると非常に有難い!ありがたやー!

82 :デフォルトの名無しさん:2009/03/22(日) 23:33:28
>>主催者&発表者各位
お疲れさまでした。なかなか楽しめました。ありがとう。
自分で触っている人あんまりいなかったのかなー。
>>81
おれ電源タップひそかに持っていったんだけど、いらなかったみたいねorz

83 :会場の人:2009/03/22(日) 23:52:12
>>82
ご協力頂き有難うございました!
思ってたより、ノートPC持ってきた人少なかったですねw


新しく買ったノートにLLVM入れたいんだけど、MinGWのインストーラが
ネットにつながってくれない・・・。('A`)

84 :デフォルトの名無しさん:2009/03/25(水) 01:42:48
海外出張と重なって勉強会に行けませんでした (泣
次回は参加するぞ〜。

85 :デフォルトの名無しさん:2009/04/30(木) 19:04:04
LLVM IRを書きだせる言語は現状、C++、C、Haskell、Ruby、Pythonの5つかな?

86 :デフォルトの名無しさん:2009/04/30(木) 20:38:18
デフォルトで入ってるOCamlが入ってないのはなんかのいじめですか

87 :デフォルトの名無しさん:2009/05/01(金) 14:52:43
LLVM IRとbitcodeの関係性って、どう理解すればよいの?

88 :デフォルトの名無しさん:2009/05/01(金) 21:14:42
LLVM IRのバイナリ表現がbitcode

89 :85:2009/05/04(月) 17:19:36
>>86
m(_ _)m
C++、C、OCaml、Haskell、Ruby、Pythonの6つですね。



90 :デフォルトの名無しさん:2009/05/14(木) 00:28:00
nVidiaのOpenCL実装にもLLVMとclangが使われているっぽい。

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022320.html



91 :デフォルトの名無しさん:2009/05/14(木) 20:53:59
http://gihyo.jp/admin/clip/01/fdt/200905/12
FreeBSDはclang使えないか模索中

92 :デフォルトの名無しさん:2009/05/19(火) 08:52:19
MacRubyもLLVM採用、とまらないLLVM人気
ttp://journal.mycom.co.jp/news/2009/04/03/051/index.html

93 :デフォルトの名無しさん:2009/07/22(水) 00:12:02
今更ネタだがホイ。

Adobe Alchemy登場、C/C++アプリをFlashで動作させる研究にLLVM技術採用
http://journal.mycom.co.jp/news/2008/11/21/005/index.html

>Alchemyで変換されたコードはActionScript 3.0よりもかなり高速に動作し、
>ネイティブC/C++コードよりは2倍から10倍遅く動作するとみられる。

94 :デフォルトの名無しさん:2009/07/22(水) 01:22:12
unladen swallow で Python も LLVMで動くようになったな。
最適化はこれからだけど。

95 :デフォルトの名無しさん:2009/07/24(金) 20:42:06
The Computer Language Benchmarks Gameに早く登場しないかな。
Java -serverがやたら速いから、比較できると良い競争になる。

96 :デフォルトの名無しさん:2009/09/19(土) 06:59:29
今更だけど、clangとllvmでFreeBSDとDragonflyBSDのカーネルコンパイルできたそうです。
・FreeBSD
http://wiki.freebsd.org/BuildingFreeBSDWithClang
・DragonflyBSD
http://leaf.dragonflybsd.org/~alexh/clang/clang.html

OpenBSDが好きでデスクトップで使ってるんだけど、FreeBSDコミュニティと違って、OpenBSDコミュニティは安定性を最重視して昔のpccに注目してるみたい。
OpenBSDカーネルのコンパイル、今度やってみようかな。

97 :デフォルトの名無しさん:2009/09/19(土) 09:01:01
>>93
今更だけど
LLVM本体のおかげで速いわけじゃないんだからその引用はどうなんだろう

98 :デフォルトの名無しさん:2009/09/25(金) 10:53:19
>>97
たしかLLVMが最適化されたAS3コードを生成するから、同機能の手書きAS3コードよりも速いとか言う話しだったと思う。
どっかでそんな速度比較記事を読んだ覚えがあるんだけどどこだったかな。

99 :デフォルトの名無しさん:2009/09/26(土) 01:30:40
それは初耳。
LLのイベントでは仮想関数の少なさ、dynamic型がない、Bytearrayによるポインタの模倣等の結果みたいな話だった。
むしろその言語の特性ではなくバックエンドのアドバンテージによるものならadobeは成果をmxmlcに取り込んでいると思うのだが…

100 :デフォルトの名無しさん:2009/10/22(木) 23:19:11
LLVM 2.6が23日に正式リリース - マルチスレッド環境により最適化
http://journal.mycom.co.jp/news/2009/10/22/049/index.html

101 :デフォルトの名無しさん:2009/10/23(金) 08:21:47
>>99
・オブジェクトだけ持ってきて利用できる
・バックエンド作るのは比較的簡単
ってことで、現状は自然なのでは?

ActionScript本体の方はいつもバタバタしてるしね。
コードも汚いし。そう簡単にLLVM化出来ない。

102 :デフォルトの名無しさん:2009/10/31(土) 08:03:06
LLVMをclang+llcでセルフビルドできる?


以前書いたややこしいCモジュールをllvmでやってみたら、gccにくらべ10%程度速くなった。
llvm-gcc -O0 -O6, clang いずれでも同様の結果になった。
llvmいい仕事してるな。

103 :デフォルトの名無しさん:2009/11/15(日) 11:25:41
llcでBitCodeからアセンブリファイル(*.s)は作れたけど、exeファイルの作り方がわからない・・・

もしかして、gccが無いとexeファイルって作れない?

104 :デフォルトの名無しさん:2009/11/15(日) 13:19:11
より厳密にはtarget向けに作られたbinutils(asとld)が必要かな

105 :デフォルトの名無しさん:2009/11/15(日) 23:32:07
mingwを導入するとよろし

106 :デフォルトの名無しさん:2010/02/09(火) 23:25:55
http://sourceforge.jp/magazine/10/02/08/0254222
LLVMのコンパイラ「Clang」、セルフホスティングに成功

http://journal.mycom.co.jp/news/2010/02/09/030/
あるコンパイラが重要なマイルストーンに到達、LLVM Clang


107 :デフォルトの名無しさん:2010/02/10(水) 15:49:51
これは凄いと思う。LLVM,SCONS、FreeBSDで
X11まで行くと、あとはGnomeだけになる。
その間に、GNUコンパイルチェーンのBSDライセンス化希望。

108 :デフォルトの名無しさん:2010/02/10(水) 19:49:18
何で全角…

109 :デフォルトの名無しさん:2010/02/10(水) 19:52:49
大事なことなので全角で書きましたが何か?

110 :デフォルトの名無しさん:2010/02/10(水) 21:15:35
GNUがわざわざコピーレフトでないライセンス使うなんて
Gnuzillaとかncursesみたいな事情があるものだけだろ
チェーンツールをBSDにする理由が無い

111 :デフォルトの名無しさん:2010/02/10(水) 23:02:53
MPLはコピーレフトだよ

112 :デフォルトの名無しさん:2010/02/11(木) 11:57:07
>>110
llvmに関しては君みたいな何かを勘違いしてる人が多くて、
嘘解説が半分くらいあるのが、日本で知らない人が多い理由だよな。
仮想マシン基盤とか言ってるサイトがトップ近くにヒットしたりするし。

113 :煽り文:2010/02/11(木) 13:09:42
ライセンスがどうとかそんなことより
俺が知りたいのは

W I N D O W $ で動くかどうかということだ!!!

114 :デフォルトの名無しさん:2010/02/11(木) 13:12:48
>>112
>>110だけど何で絡まれたのか分からん。
勘違いってMPLが非コピーレフトだと思ってたこと?
なんかこじつけくせえレスだな

115 :デフォルトの名無しさん:2010/02/11(木) 13:32:19
ごめん上げたから馬鹿に勢いを付かせてしまった。

116 :デフォルトの名無しさん:2010/02/11(木) 13:42:50
>>114
>何で絡まれたのか分からん。

「何かを勘違い」とか書いてるくらいだから、
>>112 自身も分かってないのかもよw
スルーするがよろし。

117 :デフォルトの名無しさん:2010/02/11(木) 14:19:22
>>116
スルーされてるのにスルーすればよろしって(w
なんで絡まれてるのか分からないほど馬鹿相手にしちゃったなと。
その理由は>>112君ほど酷い勘違いをしてる人間が存在してることが
llvmの悲劇だと言うことを、君に伝えてるわけではない。
と言うことくらい読解せよ。ウザイからもうレスするなお前。

118 :デフォルトの名無しさん:2010/02/11(木) 16:17:28
日本語でおk

119 :デフォルトの名無しさん:2010/02/11(木) 17:40:25
やべぇ読解できねえ

120 :デフォルトの名無しさん:2010/02/12(金) 02:33:27
>>117みたいに日本語も使えない人間が存在していることが
LLVMを日本で知らない人が多い理由だよな(キリッ

121 :デフォルトの名無しさん:2010/02/12(金) 03:13:49
clangが実用になるのが待ち遠しい

122 :デフォルトの名無しさん:2010/02/12(金) 06:09:18
>>121
セルフビルドに成功したのだから、もう実用化αというレベルだと思う。
使っていくべきかも知れない。


123 :デフォルトの名無しさん:2010/02/12(金) 08:05:47
ただしmac,linuxに限るというのもまた一面の真理。

124 :デフォルトの名無しさん:2010/02/12(金) 15:02:41
*BSDでも使えるだろw

125 :デフォルトの名無しさん:2010/04/17(土) 20:05:44
FreeBSD/CLANG ready for testing!
ttp://ivoras.sharanet.org/blog/tree/2010-04-16.freebsdclang-ready-for-testing!.html

126 :デフォルトの名無しさん:2010/04/21(水) 14:59:54
[Phoronix] Benchmarking LLVM & Clang Against GCC 4.5
http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1

127 :デフォルトの名無しさん:2010/04/25(日) 05:49:17
iPhone 用のアプリ作ってるんだけど、
LLVM gcc でも clang でも普通に動くバイナリできるな。

128 :デフォルトの名無しさん:2010/04/30(金) 22:47:00
LLVMでWindows用のバイナリ作成ってできるのでしょうか?
たとえばWindows用の実行ファイルが作れるオレオレ言語の作成って可能ですか?

129 :デフォルトの名無しさん:2010/04/30(金) 23:06:42
可能

ただし、>>103-104

130 :デフォルトの名無しさん:2010/04/30(金) 23:17:07
>>129
可能なんですね!

binutilsとか全然わかりませんがキーワードを教えてもらえたんで色々勉強してみます。
ありがとうございました。


131 :デフォルトの名無しさん:2010/05/01(土) 00:27:36
>>128
PECOFFを始めとするバイナリファイルを直接生成するプラットフォームが
現在進行中(だと思う)ので、近い将来、直接 *.o *.exe を吐けるようになるだろう。
(*.bcでないライブラリのリンクがどうなってるかはシラン)
(DLLのインポートはきっとやってくれるハズ)

まずは、tools/lli で完動する *.bc オブジェクトを吐けるようになるまでがんがれ。
あとは、Mingw の msys を拾ってきてひたすらほげれ。

つか、コンセプト作りとか実験は OSX の方が楽かもな。ちょっと回り道になるけど。

132 :デフォルトの名無しさん:2010/05/08(土) 11:54:19
mingw gcc-4.5 dragonegg のバイナリ呉

133 :デフォルトの名無しさん:2010/05/08(土) 19:40:39
まーたffmpeg or x264厨か

134 :デフォルトの名無しさん:2010/05/09(日) 00:51:03
興味本位で訊くが、その厨ってdragoneggを欲してるのか?
単にベターなコードを吐いてくれそうな処理系でコンパイルしたがってるだけか?
単にベターなコードを吐いてくれそうな処理系を持ってる奴にコンパイルさせたがってるだけか?

135 :デフォルトの名無しさん:2010/05/18(火) 22:16:34
LLVM、GCC libstdc++をBSDライセンスのlibc++へ置き換え
ttp://journal.mycom.co.jp/news/2010/05/18/045/index.html

136 :デフォルトの名無しさん:2010/05/18(火) 22:23:23
ホント、Apple 様々じゃのう…

137 :デフォルトの名無しさん:2010/05/20(木) 00:45:02
LLVMはじまってきたな

138 :デフォルトの名無しさん:2010/05/20(木) 01:34:11
LLVMというかClangでは?

139 :デフォルトの名無しさん:2010/05/20(木) 06:22:32
肝心の Code Generator がいまいちだよな。x86 では変なコードをよく吐く。

140 :デフォルトの名無しさん:2010/05/20(木) 12:16:44
日本の研究機関ではCOINS一択なのか? この分野では。

141 :デフォルトの名無しさん:2010/05/21(金) 05:57:40
COINSを使って、この分野の権威の人たちの歓心を買わうと
科研費とか得られやすいからね
COINSプロジェクトは日本のコンパイラ分野の大物がたくさんはいってるから

142 :デフォルトの名無しさん:2010/05/21(金) 06:03:26
ちゅーか、一択どころか選択肢が皆無だったからこそ
COINSなんてものが作られたわけで
別に国産に縛られずとも良いとは思うけども、
国産だったら便利なこともあったりするわけで

143 :デフォルトの名無しさん:2010/05/21(金) 07:44:41
で、COINSの成果を製品に活かしてるところがどこかあるのかね。
LLVMのほうがプロジェクトとしてはむしろ古いはずなんだが。

144 :デフォルトの名無しさん:2010/05/21(金) 12:54:44
CONIS スレは即死した。
 COINSについて語ろう
 http://pc12.2ch.net/test/read.cgi/tech/1232545653/l50

このスレはまだ生きてる。

145 :デフォルトの名無しさん:2010/05/21(金) 18:39:18
>>143
少なくとも今のところ、COINSが流行るとも思えないのは確か
GCCとかと比較して、とりたてて性能が良いとかのメリットがない
でもプロジェクトは古い方が有利では

146 :デフォルトの名無しさん:2010/05/21(金) 19:05:00
>>145
>でもプロジェクトは古い方が有利では

だからGCCが優勢なのか。


追伸 libjit でいろいろ情報を漁ると厨臭がモロ。

147 :デフォルトの名無しさん:2010/05/22(土) 01:14:27
>>146
既にclangはかなり良い性能だと思うけど、こいつでできるのは
(ネイティブコンパイルの場合)x86のアセンブラ出力まで。

こいつをCOFFやELFなどの各種OS向けの実行プログラムとしてビルド/リンクする機能がまだ揃ってない。
(GCCツールチェインの場合はbinutilsが担当している)

148 :デフォルトの名無しさん:2010/05/22(土) 06:50:25
>>147
MCが進行中だね。2.8では .ll .bc .s .o (もしかするとexecutableも) 直接吐けるようになるだろう。
asを介さずバイナリが吐けるのは結構いいかも。

clang++ が boost 作れるようになったから C++ 部が落ち着くのももうじきだな。
という俺は未だにclangを試したことがなく llvm-gcc ばかり使ってる。

つか日本語の情報が少なすぎる…

149 :デフォルトの名無しさん:2010/05/22(土) 07:49:48
>>148
clangは手元のWindows環境でHello worldが動くことは確認したよ。
最適化を掛けたらちゃんとprintfがputsに置き換えられた。

150 :デフォルトの名無しさん:2010/05/24(月) 18:03:48
>>144
COINSのセンスの無さ。
1、JAVAで書いてる
2、JAVAで書いてるのにオブジェクトの内臓を弄るような使い方
3、中間形式が2形式もある
4、中間形式が2形式もあるのに読みにくい
5、これだけ抽象化してるんだから新言語開発に使える?
  とか思っても、案外型情報とか決め撃ちしてて使いづらい。
6、CPUの新命令セットを言語からサポートさせようとすると
  当然だけど、全部に手を加えなきゃ駄目、それがまためんどくさそう。
7、多言語対応って言ってるけどもCOBOL C →ひとつの中間形式というより
  COBOL→COBOL中間形式、C→C中間形式 COBOL中間形式とC中間形式の
  文法が似てるだけって感じが色濃すぎて何がなんだか。

結局マルチCPU、マルチ言語対応のコンパイラ基盤というより、
C言語コンパイラとCOBOLコンパイラと、x86コンパイラとPowerコンパイラを
全部リンクしましたって感じ。

151 :デフォルトの名無しさん:2010/05/24(月) 18:15:02
>>150
結局文字列を高度に解析するようなシステムって、動的言語で書いた方が圧倒的に簡単なんだよね。
ハッシュやリストで済むようなことが、静的型付け言語だといちいちクラス書いてやらないといけない。
テキストパーサやコンパイラの分野のプログラムを書くと特にそう感じる。

まあ、スレ違いだがな。
10年かけてC++でシステムを構築してきたLLVMマンセーってことで。

152 :デフォルトの名無しさん:2010/05/24(月) 18:33:17
一番最悪なのが、I32やI64が決まるのが、Lowレベル中間形式に落ちてから
ここが最低最悪センス無さ杉。基本型の大きさはHiレベルで決めて、
例えば32ビット対象コードでも、Lowレベルで8ビットコンピューターに還元できるような
そういう設計が必要なんだと思う。LLVMはこれを一番気にしてる所が偉い。
そりゃ簡単には出来ないだろうけども、これを実現可能な枠組みがあれば2段階中間形式も
許されるけど、単に字句解析(これすら他者開発)を分けただけぽい2段階って何の
意味があるのか訳がわからない。

153 :デフォルトの名無しさん:2010/05/24(月) 20:01:36
LLVMも Machine**** とか後段に出てくるんだよな。
ほとんどの最適化パスでは無視できるところだが。

貴様ら llvmdev をヲチしてるか?

154 :デフォルトの名無しさん:2010/05/24(月) 20:02:17
やっぱGNUは害悪でしかないな

155 :デフォルトの名無しさん:2010/05/24(月) 20:27:45
>>153
Machine****は後段で良いんだよ、このセンスの違いが本気度の違い。


156 :デフォルトの名無しさん:2010/06/08(火) 05:41:12
[INFO]: import of clang/LLVM to happen on June 9th
http://permalink.gmane.org/gmane.os.freebsd.current/125675
"On June 9th, we are importing clang/LLVM into FreeBSD HEAD."


157 :デフォルトの名無しさん:2010/06/11(金) 12:12:02
JITが全然速くないんだけど
がっかりだ

158 :デフォルトの名無しさん:2010/06/11(金) 19:21:05
JIT 速くないの?
じゃあ、じっと待つしかないな

159 :デフォルトの名無しさん:2010/06/17(木) 12:46:37
ttp://lldb.llvm.org/
LLDB is a next generation, high-performance debugger. It is built as a set of reusable components which highly leverage existing libraries in the larger LLVM Project, such as the Clang expression parser and LLVM disassembler.
LLDB is in early development, but is mature enough to support basic debugging scenarios on Mac OS X in C, Objective-C and C++.
All of the code in the LLDB project is available under the standard LLVM License, an open source "BSD-style" license.

これも Apple が主導してるのかな

160 :デフォルトの名無しさん:2010/06/17(木) 12:48:04
Copyright見た?

161 :デフォルトの名無しさん:2010/06/17(木) 12:58:03
見てなかった
Apple Inc. って書いてあるな

162 :デフォルトの名無しさん:2010/06/17(木) 18:35:16
CLang関係に山ほど居るからな、Appleの中の人。

163 :デフォルトの名無しさん:2010/06/17(木) 19:43:34
AppleはGNU憎しでLLVMにテコ入れしてる側面もあるみたいだ。
Apple従業員はGPLv3コードに触れられないので今やDragoneggはDuncan Sandsの双腕にかかっている。

164 :デフォルトの名無しさん:2010/06/17(木) 20:40:46
GPL 自体というより GPLv3 を徹底的に避けようとしてる節はあるな
GPLv3 が無ければ CUPS の買収もしなかった気がする

後はまあ BSD 系の開発者も社内に多そうだし

165 :デフォルトの名無しさん:2010/06/18(金) 12:06:44
CUPSのデュアルライセンス化ってGPLv3以降か?

166 :デフォルトの名無しさん:2010/06/18(金) 12:48:00
買収が公表されたのは GPLv3 の正式発表後だと思う
デュアルライセンス化もこのタイミングなのかな
買収成立は公表の半年前らしいから GPLv3 の初稿からは1年経ってる

167 :デフォルトの名無しさん:2010/06/18(金) 14:49:39
2002年だからずっと前だと思うけどな。
http://www.cups.org/articles.php?L68+TNews+Q
この頃からMac OS X独自拡張がソースツリーに突っ込まれた。

168 :デフォルトの名無しさん:2010/06/18(金) 16:17:53
C++で分岐予測が外れた時どれ位のオーバーヘッドが生じるかテストしてみました
私の所の環境では乱数によるCALLでは交代CALLの約10倍のコストが生じました
(Athlon X2 5600Mhz)

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

struct foo {
__int64 start, end, freq;

HANDLE hprocess;
DWORD oldclass;

foo() : hprocess(GetCurrentProcess()), oldclass(GetPriorityClass(hprocess)) {
Sleep(10);
// SetPriorityClass(hprocess, REALTIME_PRIORITY_CLASS);
QueryPerformanceFrequency((LARGE_INTEGER*)&freq);
QueryPerformanceCounter((LARGE_INTEGER*)&start);
}
~foo() {
QueryPerformanceCounter((LARGE_INTEGER*)&end);
// SetPriorityClass(hprocess, oldclass);
printf("%d\n", (int)(end - start));
}
};}

169 :デフォルトの名無しさん:2010/06/18(金) 16:18:36
void func1() {}
void func2() {}
void func3() {}
void func4() {}
void func5() {}
void func6() {}
void func7() {}
void func8() {}
void func9() {}
void func10() {}

#define MAXITER 10000000

int main()
{
void (*func[])() = {func1, func2, func3, func4, func5, func6, func7, func8, func9, func10};

{
printf("Alternative Call : "); // 分岐予測が効きやすい
foo f;
for (int i = 0; i < MAXITER; i++)
func[i % 2]();
}

{
printf("Ranom Call : "); // 分岐予測が効きにくい
foo f;
for (int i = 0; i < MAXITER; i++)
func[(std::rand() >> 4) % 10]();
}
}

170 :デフォルトの名無しさん:2010/06/18(金) 17:21:22
rand()に時間がかかるって落ちじゃないだろうな?

171 :デフォルトの名無しさん:2010/06/18(金) 17:26:14
>>168-169
これだと rand 関数がオーバーヘッドに効いてこないか?
(分岐予測にとって) 大きめの配列を作ってその配列を参照したほうがよさそうだけど。
適当だけどこんな感じか?

#define NUMSEQ 256
void (*func[])() = /* 省略 */
int callseq[NUMSEQ];

{
for (int i = 0; i < NUMSEQ; i++) callseq[i] = i % 2;
printf("Alternative Call : "); // 分岐予測が効きやすい
foo f;
for (int i = 0; i < MAXITER; i++)
func[callseq[i%NUMSEQ]]();
}


172 :デフォルトの名無しさん:2010/06/19(土) 00:32:48
つーかそれLLVMと関係あるのか?

173 :デフォルトの名無しさん:2010/06/19(土) 00:37:35
分岐予測を誤解釈してない?

174 :デフォルトの名無しさん:2010/06/19(土) 17:03:02
WWDC Video 面白いぞ。Session 312、313、316とかがLLVMネタ。

AppleはいよいよLLVMをデフォルトコンパイラにするのか。

GPLv3がイヤなのは間違いないな。


175 :デフォルトの名無しさん:2010/06/21(月) 12:23:48
いや前からLLVM大好きだし。
PowerPCとx86の橋渡しから、
モバイルデバイスとx86の橋渡しに変っただけでしょう。

176 :デフォルトの名無しさん:2010/06/21(月) 19:28:04
それでもGPLとくにV3が怖いのは間違いないな。

177 :デフォルトの名無しさん:2010/06/21(月) 21:55:50
こわがりすぎー。

178 :デフォルトの名無しさん:2010/06/21(月) 22:05:14
怖いっつーか、使い辛いからな…

179 :デフォルトの名無しさん:2010/07/15(木) 20:00:53
MSがソフトを販売しだしてから、
プロ(代表MS)vsノンプロ(代表Gnu)の関係が築かれていったけど
これからは
フリーライド(代表Apple)と下僕(オープンソース)という関係に
なるようだ。
前者はノンプロがやりたいようにヤルで、プロは金を取って品質やサービスを
プラスアルファで提供するという関係であり、ある意味自然な関係であったと
思われるが、これからは同じ事を一緒にやって、ライドした方だけがお金を
もらうという関係なのだから、下僕は仕様すら決められない、もしくは独自仕様は
過疎仕様としてFDUによりつぶされるようになるだろう。

さよならMatz Ruby

180 :デフォルトの名無しさん:2010/07/15(木) 20:08:21
>>179
すげー勘違い過ぎてワロス

181 :デフォルトの名無しさん:2010/07/29(木) 15:11:24
(´・ω・)とーしろーな質問ですいません
LLVMとClangをビルドして、試しに作ったソースを実行してみたんだけど、include<stdio.h>を読みに行かない・・・
-IでMingWのCインクルードパス指定してやると出来るんだけど、いちいち書くの('A`)マンドクセなのです
LLVMのconfigure実行時に--with-c-include-dirs?で指定しておけば良いのでしょうか?

ソース
#include <stdio.h>

int main(int argc, char *argv[])
{
printf("hello, world\n");
return 0;
}

実行結果
C:\Temp\llvm-clang-gcc-x86>clang t.c
t.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^
1 error generated.

182 :デフォルトの名無しさん:2010/07/29(木) 15:47:36
>>181
manpage見れ。
http://manpages.ubuntu.com/manpages/lucid/man1/clang.1.html

183 :デフォルトの名無しさん:2010/07/29(木) 17:03:08
ありお
今から読んでみます

184 :デフォルトの名無しさん:2010/07/29(木) 17:51:45
(´・ω・)InitHeaderSearch.cpp修正してビルドし直すことにしたっす
>>182さん、親切にどうもでした

185 :デフォルトの名無しさん:2010/07/30(金) 00:06:41
(´・ω・)出来た、けどGCCで通る環境をそのままClangに置き換えてやろうとするとエラー(゚∀゚)
まだまだ先はながい・・・orz

(´・ω・)すんません、またとうしろーな質問なんですが
gcc -v ってやると
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw32/bin/../libexec/gcc/i686-pc-mingw32/4.5.1/lto-wrapper.exe
Target: i686-pc-mingw32
中略・・・
Thread model: win32
gcc version 4.5.1 20100717 (prerelease) (x86.generic.Komisar) (GCC)

clang -v ってやると
clang version 2.8 (trunk)
Target: i686-pc-mingw32
Thread model: posix

今使ってるGCCと作成したClangのThread modelの所が違うんだけど、WinXP上でビルドするにあたって何か問題ってありますかね?
ちょと漠然とした質問ですいませんです

186 :デフォルトの名無しさん:2010/07/31(土) 17:08:58
ClangプロジェクトのMLってcfe-devでいいの?

187 :デフォルトの名無しさん:2010/07/31(土) 22:56:27
>>186
いえす

188 :デフォルトの名無しさん:2010/08/02(月) 00:31:37
>>187
thanks a lot

50 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)