【最速へ】LowLevelVirtualMachine【LLVM】

Native用言語向け仮想機械、LLVM(低水準仮想機械)について語りませう。
いくら探しても無いので立てました。

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

まだ早い
終了

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

これって何ができるの？
汎用的なjvm?

LLVM インタープリタは別にはやくないべ
llvm-gcc で普通に native code にコンパイルしたら？
OS X 上で 32 bit モードだと llvm-gcc のほうが普通の gcc より全然早かったけど。
http://accc.riken.jp/HPC/HimenoBMT/index.html
でやりました。

CやC++やらFortranとか、もともとNative向けに作られている言語向けのVMで、
JavaVMと同じく実行時の最適化を行う。おまけに実行時に条件分岐が
どちらに飛びやすいか、どの命令が使われやすいかなどProfileを取ってバイナリ
自身を書き換え、使えば使うほど勝手に速度を増すらしい。

LLVMの実用例ってどんなのあるんだろうな

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

>>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

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

あー、仮想化としての意味合いが強いのか。なるほどthx

OpenGLのJITをLLVMのJITに置き換えただけでは?

とりあえず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関数で測定したんで、値が低いほど早いです。ソースはやや長いので書き込み不可。

>>11の
>check:41539,score:755 clock/ms
はゴミなんで気にしないでください。

(llvm-)gcc の最適化オプションは？

>>13
共に-O3です。
inline版はtemplateを多用して
いたんですが、コンパイラ的に
inline展開した中間コードを
吐くのは苦手なのかな？

う〜ん、姫野ベンチでは LLVM のほうがはやかったので、1さんがどんなソースなのか興味ありますね。どっかのアプロダに置いてくれませんか？

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

ttp://codepad.org/ とかじゃダメ？

http://codepad.org/aLVS4Jld
こんなんでいいのかな？

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

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

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

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

そのコードで inline 版とマクロ版がそんなに違うのはやっぱり何かが変なんではないかと思うな ... というか inline/マクロのちがいというより std::vector<int> と int[] の違いなのか。

過去スレ
http://pc11.2ch.net/test/read.cgi/tech/1166508605/

>>19
今回は、配列版だけしか使ってないよ。
そういえば、VCでVectorと配列で測ったら
Vector版の方が早かったよ。スレ違いでは有るけど
何でだろうね。

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

>>21
あげてくれたソースコードではコマンドラインオプションで「マクロ」を選ぶと int[] になってて、「インライン」だと vector<int> になってたけど ???

>>22
ホント？コード上はoptionの3bit目を基準に書いてたんだけど、
optionの指定も分岐も問題なさそうだよ？
環境依存か何か書いたかなぁ。

あ、なるほど、読み間違ってました、失礼。

#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 展開がされてないんではないかと気になりますね。

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

>>26
僕はその記事をまえにみたときに自分で姫野ベンチやってみたんですが、
x86 ではたしかにかなり加速しましたよ。なぜか x86-64 ではあまり加速しなかったんですが。1 さんの Linux box は もしかして 64 bit ?

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

あれ、Linux(Fedora)の標準リポジトリにもう入ってる？

MacのOpenCLもLLVM使うらしいね。
http://lucille.atso-net.jp/blog/?p=526

ttp://www.ottimo.co.jp/koike/
>OpneCLは大学や研究所関係者が泣いて喜ぶかも（笑）そしてリンク時のオプティマイズとは恐れ入りました！

注目しているのはむしろ Grand Central だと思うけどな

Xlibとか、Win32APIとか、埋め込みSQLなんかの
決まりきった設定系処理なんかにも効き目あるんだろうか？

ttp://clang.llvm.org/StaticAnalysis.html
objcスレ向きか?

しばらく前だけど、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

ttp://llvm.org/devmtg/2008-08/

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.

なんだか過疎ってるね
なんかネタない？

ttp://llvm.org/devmtg/2008-08-23/

寝る前にベンチでも取ってみようかと、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版は外部のライブラリとのリンクはまだうまくできないんですかね？

fclose

>>41
ですね･･･失礼しました；；

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

MinGWはmsvcrt.dllを使っていて、そこではcloseがANSI C標準に入っていないという理由で
_open/_closeという名前になっているのが原因か？
MinGWはろくに使ったことがないけど。

>>39
第１回勉強会か。英語で紹介されるとカッコいいなｗ
第２回ってないの？あるなら行きたいんだけど

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

>>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
正しく計測ができていなそうですが、せっかく測ったので。

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

gcc も -O3 だけじゃなくて最適化オプションいろいろ調整すれば
もうちょっとはやくなったりするので、何を持って llvm-gcc の速度というか疑問だったりするんですが。

mingwのllvm-gccとcygwinのgccで比較しちゃダメでしょ。
cygwin gccのバイナリの方がが遅いのは当たり前。

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

オレ言語コンパイラをllvm対応させるとどんなよいことがありますか？

Alchemy使ってFlash化できるかもしれない。
いや、俺まだ触ってもいないけど。

最適化とかを自分でやらなくて済むくらいかな
でもこれはgccでも一緒か。作業的にはC++で書かれてる分LLVMのが楽そうだけど

いやgccは魔境らしいからLLVMやろうぜ

一応書いておくと、LLVMの開発系MLは以下で読めるよ。

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

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

clangとLLVMをベースにしたOpenCLの実装が開発中らしい。

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

これWindowsだとどう処理されるの？
一応実行中のバイナリは書き換えできないよね？

>>57
実際のところ、実行時最適化は Windows 以外でも使われてない。

やったとしても"バイナリ"を書き換える必要はないだろうけどね

>>56
clangもLLVMもOpenCLも、Appleが主導してるようなものだからなぁ。
結局は積極的に利用するのはAppleくらいなものじゃないのかね。
LLVM-GCCもiPhoneくらいだろ？実際に使ってるの。

その実装はAAPLとは全く別でしょ。
最近VMMに買収されたらしいよ。

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

それならどのみち分岐予測が効くから違わんのでない?

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

そう？実行時に書き換える手間が減るからある程度は効果ありそうに思うけど

実行ファイルとngenのキャッシュ的なものがごっちゃになってる気がする
独自のJITキャッシュデータの話なら、書き換えできるできないの話にはならないし
実行ファイルそのものを書き換えるという話なら、USBに入れて使えない

llvm-gcc -emit-llvm -S で吐き出したコードの中に

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

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

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

llvmを使って新しいカーネル作れないかな？

LLVM の最適化は自動ベクトル化に対応しているでしょうか？

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

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

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

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

第2回勉強会をやるみたいだね。
興味のある人は参加してみては。

http://atnd.org/events/381

>>71
もう申し込んだよ。楽しみだー。

HLVMのアルファ版が出たようだ。
コンパイラや言語を自作したい人は、これをベースにすると楽ができるのかも。

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

教えてもらいたいんだけど、
LLVMのJITって
lli + *.bcのビットコードの状態じゃないと有効じゃないの？
llcでネイティブなコードした実行ファイルの状態だと
普通のコンパイラがはいたバイナリと同じ？

そう。
それにデフォルトの状態では特にJITであること生かした動作してない気がする。

>>75
ありがとう。
llvm-ldで実行ファイルできるじゃん
って思ったら.bcをlliに渡すラッパーだったｗ

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

勉強会age
このスレまだ100も行ってないのかyo

>>73
軽く読んでみた限り思ったよりHighLevelじゃないしあんまりメリットが見えない。
OCamlはかじった程度なんで間違ってたら解説よろしく。

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

>>77
もう明日か。
思いのほか人数増えちゃってgkbrしてます。入りきるかなー・・・。
色々不手際あるかと思いますがゴメンナサイ。と、今から誤っておくます。ﾋｰ

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

>>79
電源タップもって行けば会場の電源の容量は足りますか？

電源容量は・・・調べてませんがノートくらいならまかなえると思います。さすがに。
もし火を吹いたら、消火のご協力をお願い致します。w

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

>>主催者&発表者各位
お疲れさまでした。なかなか楽しめました。ありがとう。
自分で触っている人あんまりいなかったのかなー。
>>81
おれ電源タップひそかに持っていったんだけど、いらなかったみたいねorz

>>82
ご協力頂き有難うございました！
思ってたより、ノートPC持ってきた人少なかったですねw


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

海外出張と重なって勉強会に行けませんでした (泣
次回は参加するぞ〜。

LLVM IRを書きだせる言語は現状、C++、C、Haskell、Ruby、Pythonの5つかな?

デフォルトで入ってるOCamlが入ってないのはなんかのいじめですか

LLVM IRとbitcodeの関係性って、どう理解すればよいの？

LLVM IRのバイナリ表現がbitcode

>>86
m(_ _)m
C++、C、OCaml、Haskell、Ruby、Pythonの6つですね。

nVidiaのOpenCL実装にもLLVMとclangが使われているっぽい。

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

http://gihyo.jp/admin/clip/01/fdt/200905/12
FreeBSDはclang使えないか模索中

MacRubyもLLVM採用、とまらないLLVM人気
ttp://journal.mycom.co.jp/news/2009/04/03/051/index.html

今更ネタだがホイ。

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倍遅く動作するとみられる。

unladen swallow で Python も LLVMで動くようになったな。
最適化はこれからだけど。

The Computer Language Benchmarks Gameに早く登場しないかな。
Java -serverがやたら速いから、比較できると良い競争になる。

今更だけど、clangとllvmでFreeBSDとDragonflyBSDのカーネルコンパイルできたそうです。
・FreeBSD
http://wiki.freebsd.org/BuildingFreeBSDWithClang
・DragonflyBSD
http://leaf.dragonflybsd.org/~alexh/clang/clang.html

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

>>93
今更だけど
LLVM本体のおかげで速いわけじゃないんだからその引用はどうなんだろう

>>97
たしかLLVMが最適化されたAS3コードを生成するから、同機能の手書きAS3コードよりも速いとか言う話しだったと思う。
どっかでそんな速度比較記事を読んだ覚えがあるんだけどどこだったかな。

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

LLVM 2.6が23日に正式リリース - マルチスレッド環境により最適化
http://journal.mycom.co.jp/news/2009/10/22/049/index.html

>>99
・オブジェクトだけ持ってきて利用できる
・バックエンド作るのは比較的簡単
ってことで、現状は自然なのでは?

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

LLVMをclang+llcでセルフビルドできる?


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

llcでBitCodeからアセンブリファイル(*.s)は作れたけど、exeファイルの作り方がわからない・・・

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

より厳密にはtarget向けに作られたbinutils(asとld)が必要かな

mingwを導入するとよろし

http://sourceforge.jp/magazine/10/02/08/0254222
LLVMのコンパイラ「Clang」、セルフホスティングに成功

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

これは凄いと思う。ＬＬＶＭ，ＳＣＯＮＳ、ＦｒｅｅＢＳＤで
Ｘ１１まで行くと、あとはＧｎｏｍｅだけになる。
その間に、ＧＮＵコンパイルチェーンのＢＳＤライセンス化希望。

何で全角…

大事なことなので全角で書きましたが何か？

GNUがわざわざコピーレフトでないライセンス使うなんて
Gnuzillaとかncursesみたいな事情があるものだけだろ
チェーンツールをBSDにする理由が無い

ＭＰＬはコピーレフトだよ

>>110
llvmに関しては君みたいな何かを勘違いしてる人が多くて、
嘘解説が半分くらいあるのが、日本で知らない人が多い理由だよな。
仮想マシン基盤とか言ってるサイトがトップ近くにヒットしたりするし。

ライセンスがどうとかそんなことより
俺が知りたいのは

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

>>112
>>110だけど何で絡まれたのか分からん。
勘違いってMPLが非コピーレフトだと思ってたこと？
なんかこじつけくせえレスだな

ごめん上げたから馬鹿に勢いを付かせてしまった。

>>114
>何で絡まれたのか分からん。

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

>>116
スルーされてるのにスルーすればよろしって（ｗ
なんで絡まれてるのか分からないほど馬鹿相手にしちゃったなと。
その理由は>>112君ほど酷い勘違いをしてる人間が存在してることが
llvmの悲劇だと言うことを、君に伝えてるわけではない。
と言うことくらい読解せよ。ウザイからもうレスするなお前。

日本語でおｋ

やべぇ読解できねえ

>>117みたいに日本語も使えない人間が存在していることが
LLVMを日本で知らない人が多い理由だよな（ｷﾘｯ

clangが実用になるのが待ち遠しい

>>121
セルフビルドに成功したのだから、もう実用化αというレベルだと思う。
使っていくべきかも知れない。

ただしmac,linuxに限るというのもまた一面の真理。

*BSDでも使えるだろｗ

FreeBSD/CLANG ready for testing!
ttp://ivoras.sharanet.org/blog/tree/2010-04-16.freebsdclang-ready-for-testing!.html

[Phoronix] Benchmarking LLVM & Clang Against GCC 4.5
http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1

iPhone 用のアプリ作ってるんだけど、
LLVM gcc でも clang でも普通に動くバイナリできるな。

LLVMでWindows用のバイナリ作成ってできるのでしょうか？
たとえばWindows用の実行ファイルが作れるオレオレ言語の作成って可能ですか？

可能

ただし、>>103-104

>>129
可能なんですね！

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

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

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

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

mingw gcc-4.5 dragonegg のバイナリ呉

まーたffmpeg or x264厨か

興味本位で訊くが、その厨ってdragoneggを欲してるのか?
単にベターなコードを吐いてくれそうな処理系でコンパイルしたがってるだけか?
単にベターなコードを吐いてくれそうな処理系を持ってる奴にコンパイルさせたがってるだけか?

LLVM、GCC libstdc++をBSDライセンスのlibc++へ置き換え
ttp://journal.mycom.co.jp/news/2010/05/18/045/index.html

ホント、Apple 様々じゃのう…

LLVMはじまってきたな

LLVMというかClangでは?

肝心の Code Generator がいまいちだよな。x86 では変なコードをよく吐く。

日本の研究機関ではCOINS一択なのか? この分野では。

COINSを使って、この分野の権威の人たちの歓心を買わうと
科研費とか得られやすいからね
COINSプロジェクトは日本のコンパイラ分野の大物がたくさんはいってるから

ちゅーか、一択どころか選択肢が皆無だったからこそ
COINSなんてものが作られたわけで
別に国産に縛られずとも良いとは思うけども、
国産だったら便利なこともあったりするわけで

で、COINSの成果を製品に活かしてるところがどこかあるのかね。
LLVMのほうがプロジェクトとしてはむしろ古いはずなんだが。

CONIS スレは即死した。
　COINSについて語ろう
　http://pc12.2ch.net/test/read.cgi/tech/1232545653/l50

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

>>143
少なくとも今のところ、COINSが流行るとも思えないのは確か
GCCとかと比較して、とりたてて性能が良いとかのメリットがない
でもプロジェクトは古い方が有利では

>>145
>でもプロジェクトは古い方が有利では

だからGCCが優勢なのか。


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

>>146
既にclangはかなり良い性能だと思うけど、こいつでできるのは
（ネイティブコンパイルの場合）x86のアセンブラ出力まで。

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

>>147
MCが進行中だね。2.8では .ll .bc .s .o (もしかするとexecutableも) 直接吐けるようになるだろう。
asを介さずバイナリが吐けるのは結構いいかも。

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

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

>>148
clangは手元のWindows環境でHello worldが動くことは確認したよ。
最適化を掛けたらちゃんとprintfがputsに置き換えられた。

>>144
COINSのセンスの無さ。
１、JAVAで書いてる
２、JAVAで書いてるのにオブジェクトの内臓を弄るような使い方
３、中間形式が２形式もある
４、中間形式が２形式もあるのに読みにくい
５、これだけ抽象化してるんだから新言語開発に使える？
　　とか思っても、案外型情報とか決め撃ちしてて使いづらい。
６、CPUの新命令セットを言語からサポートさせようとすると
　　当然だけど、全部に手を加えなきゃ駄目、それがまためんどくさそう。
７、多言語対応って言ってるけどもCOBOL　C　→ひとつの中間形式というより
　　COBOL→COBOL中間形式、C→C中間形式　COBOL中間形式とC中間形式の
　　文法が似てるだけって感じが色濃すぎて何がなんだか。

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

>>150
結局文字列を高度に解析するようなシステムって、動的言語で書いた方が圧倒的に簡単なんだよね。
ハッシュやリストで済むようなことが、静的型付け言語だといちいちクラス書いてやらないといけない。
テキストパーサやコンパイラの分野のプログラムを書くと特にそう感じる。

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

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

LLVMも Machine**** とか後段に出てくるんだよな。
ほとんどの最適化パスでは無視できるところだが。

貴様ら llvmdev をｦﾁしてるか?

やっぱGNUは害悪でしかないな

>>153
Machine****は後段で良いんだよ、このセンスの違いが本気度の違い。

[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."

ＪＩＴが全然速くないんだけど
がっかりだ

JIT 速くないの?
じゃあ、じっと待つしかないな

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 が主導してるのかな

Copyright見た?

見てなかった
Apple Inc. って書いてあるな

CLang関係に山ほど居るからな、Appleの中の人。

AppleはGNU憎しでLLVMにテコ入れしてる側面もあるみたいだ。
Apple従業員はGPLv3コードに触れられないので今やDragoneggはDuncan Sandsの双腕にかかっている。

GPL 自体というより GPLv3 を徹底的に避けようとしてる節はあるな
GPLv3 が無ければ CUPS の買収もしなかった気がする

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

CUPSのデュアルライセンス化ってGPLv3以降か?

買収が公表されたのは GPLv3 の正式発表後だと思う
デュアルライセンス化もこのタイミングなのかな
買収成立は公表の半年前らしいから GPLv3 の初稿からは1年経ってる

2002年だからずっと前だと思うけどな。
http://www.cups.org/articles.php?L68+TNews+Q
この頃からMac OS X独自拡張がソースツリーに突っ込まれた。

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));
}
};}

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]();
}
}

rand()に時間がかかるって落ちじゃないだろうな?

>>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]]();
}

つーかそれLLVMと関係あるのか?

分岐予測を誤解釈してない？

WWDC Video 面白いぞ。Session 312、313、316とかがLLVMネタ。

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

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

いや前からLLVM大好きだし。
PowerPCとx86の橋渡しから、
モバイルデバイスとx86の橋渡しに変っただけでしょう。

それでもGPLとくにV3が怖いのは間違いないな。

こわがりすぎー。

怖いっつーか、使い辛いからな…

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

さよならMatz Ruby

>>179
すげー勘違い過ぎてワロス

(´･ω･)とーしろーな質問ですいません
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.

>>181
manpage見れ。
http://manpages.ubuntu.com/manpages/lucid/man1/clang.1.html

ありお
今から読んでみます

(´･ω･)InitHeaderSearch.cpp修正してビルドし直すことにしたっす
>>182さん、親切にどうもでした

(´･ω･)出来た、けど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上でビルドするにあたって何か問題ってありますかね？
ちょと漠然とした質問ですいませんです

ClangプロジェクトのMLってcfe-devでいいの？

>>186
いえす

>>187
thanks a lot

(´･ω･)まだかな 2.8 は

ホムペにスケジュールが出てる。9末。見るよろし。
まあ予定通りになんて逝かないだろうがな!!!

ttp://www.llvm.org/devmtg/2010-11/

誰か行かないか?

分岐地点突入(`･ω･´)？

いつものごとくgdgdが待ってるよ!!!

順調にいっているのかな+(0ﾟ･∀･) + ﾜｸﾃｶ +

mingw での clang ビルドが失敗してるぞ！！実行するとntdll.dllエラーヽ(｀Д´#)ﾉ ﾑｷｰ!!
前はビルド＆実行共に出来ていたのに何故･ﾟ･(つД`)･ﾟ･ ｳｪ―ﾝ

きみのmingwは俺のmingwと違うようだな。


マジレスすると、俺がつかってるのはmsysgit.

やい llvm！！
libdir とか includedir で dir 指定してもインストール先指定が無視されるｼﾞｬﾏｲｶヽ(｀Д´#)ﾉ ﾑｷｰ!!

バグレポしろ。どうせ放置されるか瞬間で却下されるかだろうがな!!!

もうすぐ2.8出ちゃうから早くしたほうがいいぞ。

2.8には反映されないからマタリしていいぞ。

9/20 Pre-release 2 testing begins か。
LLVMってリビジョンでのアップデート無いってことは
リリース前に試してバグレポ出すべきたぐいのもの？

ToT を使うべし。リリースなんて飾り。ToT

>>197 続き
win 上で llvm とかやろうとするのがそもそも間違いなのか
llvm は mingw+msys で build しているんだけど、公式だと msvc2008 での説明だしな
まぁ mingw+msys だと環境の縛り(tool の version とか)が厳しいせいかもだけど・・・

あ、後バグレポは・・・無理・・・
英語ﾀﾞﾒﾎﾟな人間なんで・・・orz

FILENAME : t.c
#include <stdio.h>

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

なるものを、以下の HP を参照して llvm で build しようとしたら・・・
ttp://blog.kmckk.com/archives/2435798.html
1. llvm-gcc -emit-llvm -S t.c
2. llvm-as t.s
3. lli t.s.bc

D:\My Developments>lli t.s.bc
hello, world
Stack dump:
0. Program arguments: lli t.s.bc
7C95B21A (0x00B6AD24 0x008F094B 0x00B6AD24 0x00000086), RtlpWaitForCriticalSection()+0091 bytes(s)
7C941046 (0x7C809C2B 0x003E7530 0x0022FB78 0x003E5230), RtlEnterCriticalSection()+0070 bytes(s)
008F19B6 (0x7C95005D 0x77BDC2DE 0x003E0000 0x00000000)
008F1BBD (0x0022FB4C 0x7C94E920 0x7C950060 0x00B667E8)
008F2037 (0x003E74F0 0x00AAEDD7 0x0022FFE0 0x00000000)
008E2606 (0x00000000 0x00000000 0x00D24410 0x0022FF0C)
77BE9E90 (0x00000000 0x00D38308 0x00000038 0x00000000), exit()+0018 bytes(s)
005D5567 (0x00D24428 0x003E6894 0x0022FFE0 0x00D10B3C)
00D24428 (0x00000020 0xFE020000 0x00000000 0x00000000) <unknown module>

一応、結果は表示されてはいるのだけど・・・あれ？何で dump が・・・
lli に何か bug があるのか、それとも表示するのが仕様なのか・・・orz
ちなみにこの表示がされたと同時に >>195 でもカキコした ntdll.dll エラーが発生＼(^o^)／ｵﾜﾀ

連投すまそ

--with-llvmgccdir
Specify location of llvm-gcc install dir (default searches PATH)

これ、default searches PATH ってなってるから他の win 側で設定した path も見に行くものだと思っていたら、此処にしか見に行かないのか・・・ヽ(`Д´)ﾉｳﾜｧｧｧﾝ

Cygwin にかまけてる間に Mingw で動かなくなった糞。

ちなみに連中が持ってる buildbot に Mingw の動作テストはない!!!

>>203
MSVCベースじゃないWin32も, Cygwin も、需要はあるでしょ。
最近MLじゃMSVCビルドに固執してる連中が増えてるがな!

>203
じゃああきらめてCygwinでやれ、拍子抜けするぐらいあっさりmakeできる。

バグレポなんてmingw+msysのこれこれのバージョンでやったとか
コマンドラインでどういうconfigure オプションつけたとか、
makeが成功してるけどインスコdir指定が利いてないということがわかる程度のログとか
そういうのつけてあれば、カタコトでwhy is it wrong? くらいの文章あればイケる。
いけると信じて出せ。おれは保証しないけど。

llvmいじるのが目的ならもうCygwin(ただし1.7に限る)の方がよい。
FedoraとかのLinuxの方がもっとやりやすいが。

ところで Cygwin 上で作ったバイナリ(特に clang.exe)の起動が糞遅い。
どうにかしてくれよ。つかいまどうにかしようとしてる。

何もいうことねえけど頑張れとだけいっておく。

>>206 は単純なミスだった。Mingw で clang hello.c 程度は問題ない。ヘタすりゃ selfhost だってできらぁ。


FAQ とは思うが gcc -MM で吐いた *.d ファイルを理解できない make が存在する!

まじで29日にリリース出来るのかしら(´･ω･`)？

LLVMは何でこうも絶対パス命ばっかなんだ？相対パス＆環境変数も参照するようにしろよ！！
いろいろ使いにくいだらが(# ﾟДﾟ)ﾌﾟﾝｽｺ!!

理由があって絶対パスじゃないような気がするんだが、ためしに相対パス化しようとしておもいっきりハマって以来手をつけてない。
つかWindowsでなければ相対パスとか使わんだろ?

まさにその Windows なんだよヽ(`Д´)ﾉｳﾜｧｧｧﾝ

相対パスで動いてるのは clang.dll と、あとは bugpoint くらいだ。

困ったことがあったらどしどしここに書き捨てるよろし。

ハードリンク？出来るようにするソフトもあるにはあるけど、なるべく開発ツール側で対応して欲しいんだよね
贅沢な悩みなのか・・・

>>215
レス、ありお

cmakeも絶対パスなんだよな

2.8リリースマネージャはかなり頼りない。やっぱターニャだよな!?

意表をついて三日後くらいに3.0とか5.0とかがリリースされて欲しい。

(´･ω･)さて、Xデーが近いわけだが・・・リリースは大丈夫かね？

OSSで意表ついて別の完成バージョン出すのは駄目だろ。Appleはたまにやるが。

んで2.8出たの？

(´･ω･`)まだ

月曜日まで引き延ばすと誰かが言ってたな。

ところで公式Gitリポジトリはまだかよ!

(´･ω･)Buildbot の結果が酷いお・・・

9/20 ? Pre-release 2 testing begins
が太文字状態なんだけど、まだこのレベルという事なのか(ﾟ∀ﾟ)？

落ち着く気配がしないお(ﾟ∀ﾟ)

さっき見てみたら
10/4 ― Release!
（太字）になってたけど、サイトはまだ2.7が最新になってるな。
どの標準時で考えての10/4かわからんけど、とりあえずそろそろってとこか。

ひとまずageとこう

いま Chris とかがいっしょうけんめい release notes 埋めてるし!

(´･ω･)リリースが出来ていないのにリリースとはこれ如何に
何時になったら出るんだヽ(`Д´)ﾉｳﾜｧｧｧﾝ

リリース・・・
(ﾉ・∀・)ﾉ　＝＝＝＝＝┻━┻))ﾟДﾟ)･∵.
ってこと(ﾟ∀ﾟ)？

やっとリリースがｷﾀ――(ﾟ∀ﾟ)――!!

が、win 版は・・・不遇だお(´･ω･`)

あえて言うが clang/windows はまだオモチャだ。

まだ自分で試さずカキコするが、Cygwin Mingw で --enable-shared が効くようになってるハズ!

(´･ω･)llc バージョンを見ようとしただけで dump 吐くお・・・ヽ(`Д´)ﾉｳﾜｧｧｧﾝ
直ったかなぁと淡い期待をしていたんだけど、やっぱり libdir, includedir の指定も効果が無いし・・・

バージョン 3.0 位までには、動くようになって欲しいお(´･ω･`)

>>236
まるでソースコードが悪いせいみたいに書いてるけど、
すでに方々で実用化されてるモジュールなわけで。
自分の書き方や作り方が悪いせい、という考えはないんかね。

>>236
過去ログでdir指定きかないっていってた人なら、バグレポ出しとけよ。
バグレポも出さずに勝手に期待して、裏切られたみたいなことを呟くのは
あんまりいい気持ちしないよ。

違ったら酢慢湖。

>>236
どの環境でどの配布物を使ったか書いてくれ。エスパーまんどくせい。

まだまだデベロッパ都合が多いのは仕方がないと割り切ってくれ。

(´･ω･)そうだよなぁ、バグレポ出さないのに要望だけは言いまくるってのはあれだよなぁ・・・
だが、それが 2ch クオリティー(ﾟ∀ﾟ)・・・すいません、ごめんなさい、石は投げないで・・・orz

llc 何とかとか libdir 何とかは、以下の configure で build して出来たもの
色々間違ってるかもだけど・・・

llvm rev-115770 (SVN 2.9)
../llvm-2.x/configure --prefix=/llvm_new --build=i686-pc-mingw32 --target=i686-pc-mingw32
--libdir=/llvm_new/i686-pc-mingw32/lib --includedir=/llvm_new/i686-pc-mingw32/include
--enable-optimized --enable-assertions --enable-jit --enable-threads --enable-pic --disable-shared
--enable-targets=x86,x86_64 --with-built-clang=no --with-optimize-option=-O2 --with-llvmcc=none

エスパーしてみせるが ATI とか NVIDA 配布の llc が起動してたりしないよな?

llc -help を試せ。それ以外のツールも試せ。
それでわかんなかったらビルドログを make VERBOSE=1 で取得して bugs へ池

あと、make install する前に Release+Asserts/bin ができあがってることを確認し
その配下に生成されている実行形式を片っ端から試せこんちくしょう。

(´･ω･)llc じゃなかった・・・lli だった・・・すまそ
取りあえずもう一回 build して確かめてみるお

lli だけなのか起動しないのは?

bugpoint.exe
llc.exe
lli.exe
llvm-ar.exe
llvm-as.exe
llvm-bcanalyzer.exe
llvmc.exe
llvm-diff.exe
llvm-dis.exe
llvm-extract.exe
llvm-ld.exe
llvm-link.exe
llvm-mc.exe
llvm-nm.exe
llvm-prof.exe
llvm-ranlib.exe
llvm-stub.exe
opt.exe
tblgen.exe

のファイルの内 llc.exe と llvm-stub.exe だけ

ﾁｶﾞｯﾀ lli.exe と llvm-stub.exe ですヽ(`Д´)ﾉｳﾜｧｧｧﾝ

lli.exe を実行すると ntdll.dll で不具合発生しましたと windows がダイアログ表示してくる
以下、実行時プロンプトに表示された llvm 側が吐きだした dump 結果・・・なのかな

C:\llvm\bin>lli --version
Low Level Virtual Machine (http://llvm.org/):
llvm version 2.9svn
Optimized build with assertions.
Built Oct 7 2010 (23:52:37).
Host: i686-pc-mingw32
Host CPU: core2

Registered Targets:
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
Stack dump:
0. Program arguments: lli --version
7C95B21A (0x00B70C64 0x008F966B 0x00B70C64 0x003E3C40), RtlpWaitForCriticalSection()+0091 bytes(s)
7C941046 (0x7C809C2B 0x003E3C48 0x0022FA28 0x003E53B8), RtlEnterCriticalSection()+0070 bytes(s)
008FA6D6 (0x7C95005D 0x77BDC2DE 0x003E0000 0x00000000)
008FA8DD (0x0022F9FC 0x7C94E920 0x7C950060 0x00B6C7C8)
008FAD57 (0x003E74C0 0x00AB4A83 0x0022FFE0 0x00000000)
008EB326 (0x00000001 0x00000000 0x00B6FC00 0x00000000)
77BE9E90 (0x00000001 0x00B6FC00 0x003E2C4C 0x00000007), exit()+0018 bytes(s)

llvm-stub.exe のはこれ

C:\llvm\bin>llvm-stub --version

C:\llvm\bin>lli: error loading program 'llvm-stub.exe.bc': No such file or directory
pure virtual method called
terminate called without an active exception

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

どのmingwだ? どの msys だ? gcc のバージョンは?

lli.cpp の atexit() 呼んでるところを頃してみそ

あ、後 config.log の後半に libdir とかの部分があったんだけど

部分抜き出しで掲載
## ----------------- ##
## Output variables. ##
## ----------------- ##
LLVM_INCLUDEDIR='/llvm_new/include'
LLVM_LIBDIR='/llvm_new/lib'
includedir='/llvm_new/i686-pc-mingw32/include'
libdir='/llvm_new/i686-pc-mingw32/lib'

## ----------- ##
## confdefs.h. ##
## ----------- ##
#define LLVM_LIBDIR "/llvm_new/lib"
#define LLVM_INCLUDEDIR "/llvm_new/include"

(´･ω･)どゆこと？libdir で指定するのは llvm の lib のインスコ＆参照先ではなく、違うやつのってこと？
つか、もれが大いなる間違いをしているだけなのか・・・orz

バグレポできないとかなんとか言ってる割に
ぜんぜん再現性情報もださないとなると、
誰も追試できないから調べようにも調べられない。
つまり、こいつは別に誰の助けも必要としてない、ということだ。

GCC は自前 gcc version 4.5.2 20100930 (prerelease) (GCC)
MSYS は MinGW-w64 の所にある MSYS-20100911.zip を使ってるです

>>251 の GCC
mingw_new_gcc-4.5.2_sjlj_x86_dist_full_pack.7z
http://www.mediafire.com/?7rh2znqqyao0d

(´･ω･)長々とすんませんでしたお
今日は、寝ますです

>>251
自前じゃなあ。配布物で出直してこい。貴様ビルドの話はそれからだ。

(´･ω･)お騒がせしました、MingW 公式のだと問題無かったDEATH
llvm-stub は、何か error が出るけど、対象物が見つからない
もれの自前 GCC がタコなだけだったのか(ﾟ∀ﾟ)・・・(´;ω;`)ﾌﾞﾜｯ

gcc version 4.5.0 (GCC) - llvm rev-115770 (SVN 2.9)
-----------
C:\llvm\bin>lli --version
Low Level Virtual Machine (http://llvm.org/):
llvm version 2.9svn
Optimized build with assertions.
Built Oct 8 2010 (13:46:06).
Host: i686-pc-mingw32
Host CPU: core2

Registered Targets:
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
-----------
C:\llvm\bin>llvm-stub --version

C:\llvm\bin>lli: error loading program 'llvm-stub.exe.bc': No such file or directory

>>254
> C:\llvm\bin>llvm-stub --version
>
> C:\llvm\bin>lli: error loading program 'llvm-stub.exe.bc': No such file or directory

llvm-stub.exe は、ほげ.exe にリネームし、ほげ.exe.bc を配置しておくような
使い方を想定してんじゃネーノ? つか Win32 でこれを活用してるヤツなんているのか?

で、あらためて貴様ビルドの gcc を調査するとよい。誰も喜ばないような気がするが。
念のため言うがLLVMと関係のない質問をここでするなよ?

で、 clang は Windows で使い物になるの?

>>255
(´･ω･)ありお〜取りあえず自前のGCC見直してくる

JITコンパイルも実行時最適化も無い世の中じゃ

(´･ω･)舞い戻って来た・・・
どうも自前 build した pthreads-w32 2.9.0 GC-static が原因だったみたい・・・
komisar 氏の GCC version 4.4.5 では問題無く build 出来るのに、何故(´･ω･`)？

pthreads-static って小細工ナシにリンクして動かせるの?

(´･ω･)これで解消されるんでなかった？
ttp://sourceware.org/ml/pthreads-win32/2010/msg00006.html

>>(´･ω･)
もうLLVM関係ないんやから、↓あたりに移住してね

Cygwin + MinGW + GCC 相談室 Part 5
http://hibari.2ch.net/test/read.cgi/tech/1269400706/

じつはべみょーにLLVMと関係あるがあっちのスレもヲチしている俺に死角はなかった。

(´･ω･)すまん、スレチだが最後に書かせてくれ

>>259
pthreads-w32 2.9.0 GC-static が原因っていえば原因だったのだが、libpthreadGC2.a が悪かったのではなく
もれが libpthread.a なるコピーを作って、一緒のディレクトリに置いたまま llvm を build したのが悪かったみたい
libpthreadGC2.a のみにして build したら問題無く出来た（自前GCCでも問題無かった）
後、build した後だったら libpthread.a が同じディレクトリにあっても問題無かったです

今まで、こんなもれに付き合ってくれてｱﾘｶﾞﾄｳでした(´･ω:;.:...

FAQ
ネイティブなのに仮想機械とはこれ如何に？

端的に言えば「実行用の仮想機械」ではなく「最適化用の仮想機械」ってことで。
もともとはJITもふんだんにすることになってたんだがいつのまにかそれは脇役に。

え、JIT脇役になっちゃったの？

実行時のプロファイル使った最適化ってまだスタブだけある状態？

>>265
昔から中間言語に仮想機械マシン語を採用する実装はある。

中間言語の仕様、まだ決まって無いの？
まだ拡張してたりする？

コア部分はとっくに。拡張はされてる。

>>269
gccが典型例。
一旦仮想的なマシン語に変換してから再度ネイティブなアセンブリ言語に変換する。

RTLもGIMPLEもアセンブリのままなんじゃない?
バイナリコードになるわけじゃない。
仮想機械というにはやはりバイナリ。

中間コードをarch毎に最適な命令になるようにしてるみたいっだった

LLVM Clang、Linuxカーネルビルドに成功
http://journal.mycom.co.jp/news/2010/10/28/005/index.html

LLVM CLangへの意向を表明しているFreeBSDのケースじゃ報道されないのに…

FreeBSDはおわコン

FreeBSDではニュースにならんからな。

おい devmtg 2010 に逝く奴レポよろ

ここか。
誇大広告かよ

LLVM自体は面白いし将来性抜群なんだけど、周りの無理解っぷりが…
みんな最初、配布物ビルドして走らせて、がっかり来るよな?

以前アセンブラコード吐かせて、インライン展開や構造体をばらしたり不要コードを除去したりと
プログラム変換は頑張ってるけど、x86自体を利用した最適化が最悪に近いのを見てげんなりしたな……。
インライン展開なんかはフロントエンドでもできるんだから、バックエンドでしかできない
レジスタ割付などをがんばれって思った。

今はどうなんだろう。

実行時の最適化が売りじゃなかったんか

>>283
実行時の最適化はできるけど、
そこからどういうCPU向け機械語を
吐き出すかはまた別の話なわけよ。

>>283
JVMと同じJITですよ。
JVMと違って、中間機械語がかなり低レベルで、
特定のプログラミング言語向きじゃないってだけ。
ターゲット上の最適化なんてもっと先の話。
gccをCLangで置き換えるのはかなり先になるよ。

>>285
>>275でのLinuxカーネルなんかもJITコンパイルされてるの？

いや現状-O4とか--emit-llvmとか指定しないとふつーのネイティブコード吐くだけでJITとか全く関係ない。
関係ないけどOSのカーネルをJITコンパイルとかすげー遅そう。

bcを配布しといてインストール時にCPUに合わせてコンパイルならいいかも。

>>287
Transmeta Crusoeがやったよー。> カーネルのJIT
「この速度、消費電力ならx86のままでいいじゃん」くらいのレベルには達していた。

>>288
というか、一旦JITしたら、ファイルで保存しとけばいいんだよね。
書き込みが発生すると最初の実行が遅くなって印象悪くなるだろうけど、
最初から全部やらずに少しずつサボりながらやれば…

>>289 >>290
へーもうあるのか。
遅延JITコンパイル（仮称）なんかしたらモジュール？のJITの順番とかでまた最適化の泥沼が発生しそうだな…

JITじゃないけど…
Mac OS Xは、ダイナミックリンクのアドレス解決をインストール時にやってるよね。
ライブラリのアップデイトをすると、芋蔓式に全部計算し直す。
実行時にも再計算する必要があるか確認して、必要ならやる。

prelinkはASLRに良くない

clang で Win32 x64 に挑戦してるのだけど困難がいっぱいです。
お前ら助けてくだちい。

僕は「x64なのにwin32とはこれいかに」ってレベルの人なので…

(´;ω;`)ﾌﾞﾜｯ

>>232
Windowsでもbindやrebaseをインストール時に行っているソフトはあるよ

LLVMて思ったより流行ってないな

はやるのはあと10年かかるとおもうね。
MS当たりが.NETとかにしれっと組み込んでくるかもしれないけど。

一般的に流行らんでもアポがclangともどもGCC代替目指してるうちは安泰だしな
FreeBSDみたいな大御所も積極的だし、MSも価値ありと踏めば実装するだろうねぇ

てかそもそも一般のプログラマに流行る必要あるんだろか
10年後に、いつのまにかGCCのない世界で同じ仕事続けてるっていう未来は有るかもしんないけど
LLVM自体を活発に弄くり倒す人達はいつまでも少数派な気が

いみふ

誰か翻訳頼むわ

『Apple や FreeBSD がリソースを割いている間は、流行っていなくとも心配無用。

>>300 の住んでいる世界では、普通のプログラマは自分が使うコンパイラが
何であるかに無関心で、使用するコンパイラを能動的に選択する事は無い。
コンパイラの選択はごく少数の人達が考えれば良い話で、一般のプログラマの
間で LLVM に対する関心が高まる事は必要ない。』

って事じゃないの?
>>300 が何故そう思ったのかは謎だけど。

MS の下りは俺も理解出来なかった。

「だろうねぇ」「だろか」「しんないけど」「気が」
結局何を言いたかったんだろうな

＞普通のプログラマは自分が使うコンパイラが何であるか

こんな意訳が出るようじゃ>>300の言う事どころか
LLVM自体が今現在どのような使われ方をしているのか分かってない証拠だな

>>300=305

これはひどい

google NaCLで採用されるってな。
しかも、クロスプラットフォームだってさ。
これで、低速なFlashともおさらばだ。やったね。

msilでよくね？

それはイラネ

まぁ、MSILとLLVMはちょっとした変換でできるんだけどね。

まじで！？

>>312
https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/MSIL/?sortby=file&pathrev=107482

ん？
MSILバックエンドはバグだらけで、2.8からはリリースからも外されたんじゃなかったっけ？

Monoもやってるよね。

April 6, 2011: LLVM 2.9 is now available for download!

2.9リリースage

で、2.9 の何が嬉しいの?
あえてきいてみる。

Win32向けのサポートはかなりよくなってるハズだから。

いちいち二度もageるような朗報ではないということだけは言える。

個人的にはC++0xの対応が進んだ（2.8比）のが嬉しい。
gccと比べるとまだまだではあるけど。

age

インクルードパスを環境変数も見に行くように早くなってくれお…

http://www.aosabook.org/en/llvm.html

https://github.com/kripken/emscripten

とりあえず日本語にしてくれ

うーん…
iPhoneアプリ、llvmをコンパイラに指定すると起動した瞬間に落ちる。
規模の小さいテストアプリはllvmでも動くんだけど。

つまりllvm以外だと落ちないの？

>>327
llvm compiler1.5
llvm gcc 4.2
どっちもだめ

ただのgcc 4.2でずっと開発して来て、
こちらなら何十時間も安定動作してる。

xcodeは3.2.4

iPhoneアプリのコンパイラをGCCじゃなくてLLVMにすることのメリット、デメリットって何？

デメリット
ひとつ上のレス

メリット
無し

デメリット
変なコンパイルエラーが出る
　{standard input}:unknown:Undefined local symbol LBB46_-1　とか、なにこれ？
　最適化レベルが上がると出やすい
実行速度がちょっと遅い？

メリット
若干実行ファイルサイズが小さい




過疎ってるな。面白そうなのに、語りたいやつ居ないのか…

>>331
俺は興味があったから先週読み始めたが、まだ理解が進んでないからスレに書くこともない

何かがおかしいと思うのなら、最新安定版かtrunkで再現するか確かめてから
llvm-devかBugzillaに小さいテストケース送った方がいいぞ
OSSでもプロプラでも、開発者が知らない問題は滅多に解決しないし
作者が目を通していると公言しているのでもない限り
2chやブログに書くのは開発者に伝える手段にはならないと考えた方がいい

あと、LBBはBasicBlockのことのような気がするが自信がない
LLVMとClangをgrepしてもそのメッセージは見つからなかったし

こっちに張った方が良かったな

http://chris.wailes.name/?page_id=97

Linuxのrpmで手に入るllvmの使い方がいまいち解からん。
llvm-g++はどこへ行ったんだ？

どのディストロだ?

ところでとうとうChrisが「Gitも悪くない、Gitへ移行する障壁は?」とか訊き出したぞ。

>>335
Fedora13

Gitってなんかマズイの？

>>334
llvm-g++は消えた。CLangに注力。
FreeBSDがgccからCLangにメインコンパイラを移行する計画らしい。

マジか・・・。C++まともに使えないじゃん。

llvm-gccの後継はdragoneggらしいよ、GCCプラグインの。

龍の卵か、プラグイン化されてんのがおもしろいね。

関係ないけど、LLVMのブルーアイズなマスコットがオサレ。

>>338
Clangはboostをコンパイルできる状態だぜ。
http://clang.llvm.org/cxx_status.html

>>341
まじか。boost spirit行けるならgccから移るわ。

>>341
特殊化バリバリのメタプログラミングでlispの一部を
実装したコードをコンパイル出来た。準拠度がパネェわ。

typedef ES
<
Quote,
ES< Quote,int,Key<0> >,
ES< Quote,int,Key<1> >,
ES< Quote,long,Key<2> >
>
structure;

typedef Nelsp<ES< Cond,ES<T,ES<Quote,int> > > >::cell ret;

Structure< structure > value;

なんという地獄コード。

何をやってるのか読み取ることさえできんｗ

>>341
このページ"Projects Building with Clang"の段落が昨晩なくなってる。
古い情報だけどキャッシュから貼っとく。テーブルは見にくいから箇条書きに治す。

Projects Building with Clang

Clang is now capable of compiling large C++ projects, and the following table describes various projects that we have attempted to compile with Clang++.

Project
Status
Last Tested
Tracking Bug
Clang and LLVM
Successful self-hosting achieved
Continually
CMake
Compiles, passes regression tests (debug build)
February 9, 2010
Boost
Compiles and passes regression tests on Darwin/X86-64.
May 20, 2010
PR6023
Qt
Partially compiles; miscompilation of uic prevents complete compilation, qmake works, some small examples also.
February 9, 2010
PR5881

中途半端なトコで送信してる。まぁ、いいか。

ヘッダファイルをコンパイル対象にしても
エラー吐かなかったから、本当に動くコード吐いてんのか動作も確認してみた。
ちゃんと1が戻ってくる。いいねぇ。

typedef short Sample;
typedef Nelsp
<
 ES
 <
  Eval,
  ES
  <
   Quote,
   ES
   <
    Cond,
    ES< ES< Eq,char,Sample >,ES< Quote,Key<0> > >,
    ES< ES< Eq,short,Sample >,ES< Quote,Key<1> > >,
    ES< ES< Eq,long,Sample >,ES< Quote,Key<2> > >,
    ES< ES< Eq,float,Sample >,ES< Quote,Key<3> > >,
    ES< T,ES<Quote,ES< Quote,Key<5> > > >
   >
  >
 >
>
::cell ret;

std::cout<< Nelsp< ES< Car,ret > >::cell::value << std::endl;
.//一応説明。CondのEqでSampleの型を判定して条件に一致するKeyを返し、
//そのKeyからenumのvalueをとりだしてんのね。

Cygwinでビルドした clang.exe が起動激遅。clang --helpですら1秒くらい時間を要する。
(もちろん最適化ビルドだよ)

Cygwinスレできくべきか? だれか原因を知ってたら教授と助教授と准教授をください。

真面目に答えようかと思ったが
最後の一言が余計だったな

Cygwinだから遅いんじゃない？
>>350 参考までに教えてくれ

>>350
知らないなら黙っとけポス毒

>>349
間違う人、職場でも多いけど、
「教授」じゃなくて「教示」な。

そこは文字掛けだったのか

>>353
間違いではない。
元々「教授」というのは「習い」と同じ意味。
だから与えるのではなく授かるになってる。
それが転じて「教授」してくれる先生も指すようになった。

必携類語実用辞典より
＃（自分側に）　お教えいただく　お導きくださる　お示しくださる　お教導賜わる　ご教示を煩わせる　ご高示に接する　ご指導を仰ぐ　

>>355
「教授をください」が正しいと。

父「お前にうちの教授はやらんぞ！！」

つまり准教授は不要と。

LLVMとJavaVMのバイトコードのトランスポーターって出来無いかねぇ。

LLVM IRは(各アーキ用の)汎用アセンブラみたいなものなので困難。
つかいろいろセマンティクス違うだろ?
LLVM IR は、生アセンブラをプロシージャ単位にして型厳格にしたようなもの。

勇者の挑戦を止めはしない。目が出そうだったら俺もプッシュしてやる!

両方ともチューリング完全だと思うから
理論上は出来るんじゃないかな。
あとは、llvm to javascriptのようなことをやってのける気力だけ

$ clang -emit-llvm main.cpp
clang: error: 'x86_64-redhat-linux-gnu': unable to pass LLVM bit-code files to linker

あん？
なんか設定の不備？
それとも、x64じゃJITはまだ対応してないって事？
それとも、JIT自体未だ未実装って事なんか？

clang -emit-llvm -S
clang -emit-llvm -c
は動くだろう。

動くっちゃ動くけど、実行ファイルつくるのはどうすんの？

$ clang -O3 main.cpp -o a.out

>>365
いやそれは動くよ。
問題はJIT用の実行ファイルをどうやって作るかってとこ。

$ clang -O3 main.cpp -emit-llvm -c -o main.bc
$ lli main.bc blah blah

ひとつ付け加えておくが lli つーか LLVM JIT は JIT 最適化とかそういうものを実装しているワケではない。
単に JIT コンパイルするだけ。
"JIT最適化やりたいヤツは llvm::ExecutionEngine および Transforms でがんばれや" ってことでひとつ。

>>368
あんがと。てかLLVMのVMを実行ファイルに埋め込める訳じゃないんだね。
3年前llvm-gccでコンパイルしたとき実行ファイルが数十MBと異常なサイズだったから
実行ファイルに処理系内蔵して、データとしてbitcode実行してたのかと思ってたけど。

elfとかpecoffへのbitcode埋め込みは、方針が固まったら提案してみる、つか実装してみる。
type system rewrite がひといきついて

…ついてない。dragoneggがいまだヌッ壊れたままだ。

>>368
clang からbitcodeのオブジェクトファイル吐かせて、
llvm-linkでリンクしたbitcodeを作成、
作成したbitcodeをlliで実行ってのができるようになったよ。

でもclangからllvm-linkに渡さなきゃいけないのがメンドイ。
clangだけでリンクしたbitcode吐く方法しらない？

面倒でも何でもない

そもそも clang driver が bitcode に無知のような気がする…
clang 連中にとっては LLVM は単なる Code Generator なので
BitcodeをClangでどうこうしようとしてる奴がいなさそうな。

実際、 -O4 は -O3 -emit-llvm とほぼ等価だったはずだが、
clang は何も考えずに *.o (中身は*.bc)をldに渡している。
gold llvm lto plugin (もしくは apple ld)がそれらをうまく扱うことを期待している。


llvm-link で生成したBCはちゃんとopt -std-link-opts で最適化するんだぞ。
llvm-ld はあまり信用してないので知らん。

というかclangの中の人はAppleの人

optなんてコマンドあったんだ。
llvmとか接頭辞がないからわかりづらずぎる。

NaClで採用されたっていうけど、bitcodeの状態だとAPIに依存しなけりゃクロスプラットフォームなのか？
まぁ、エンディアンとかレジスタのビット幅もあるかもしれないけど。

LLVM 3.0 いつ？

>>376
「VM」の意味をよく考えろ。

>>378
JavaVMみたいなクロスプラットフォーム前提の設計ならともかく、
最適化目的なら機種依存もありうると思ったんだけど。
現存するVMだって機種依存するものはあるし。

Mac OS XでPowerPCとx86の差を吸収するために使われてた。

レジスタサイズ整数とかアドレスサイズ整数とかが無いからクロスプラットフォームにしてもいまいち使い辛いんでないかい

llvm ってオレオレ VM を作るためのフレームワークとかツールキットっていう位置づけで出てきたんでしょ。
最適化は「将来的には夢が広がりんぐ」って形で最初からあったけど、llvmが最適化目的のプロジェクトというわけじゃないよ。

>>381
クロスプラットフォームにはない方がむしろいい。

>>383
sizeofってどうなんの？
あり得ないと思うけど、
bitcodeの実行先で決定?

>>383
int変数一個をbitcodeにするだけで32ビットと64ビットで互換性なくなるんだぜ
iregとか書きたいよ

>>384
それはfrontendが決めること。
llvmはターゲットに応じて適切な機械語に変えるだけ。

じゃあbitcode上のレジスタサイズは一応決まってんだ。
少なくともintとlongが異なるのにそれぞれに割り当てたレジスタが
同じサイズになったりしたら困るもんね。

bitcodeのレジスタサイズ？
http://llvm.org/docs/LangRef.html
みながら
http://llvm.org/demo/index.cgi
でコンパイル結果みて
http://llvm.org/docs/LangRef.html#datalayout
あたり読めば疑問は解決すると思う

なるほど。そもそもレジスタサイズの話は中間言語一般の話でLLVMとは関係なかったな。

インラインアセンブラ使ったコードコンパイルしてみた。
call void asm sideeffect "mov %eax,%ebx", "~{dirflag},~{fpsr},~{flags}"() nounwind, !srcloc !0
カプセル化されるのか面白いな。

>>386
inttoptrとかどーするのよ

揚げ足だけど、整数からポインターへの変換が必要なようなアホコードは捨てろよ。
Memory Maped I/O ぐらいでしか必要ないでしょ。

整数とアドレス値の境目のなさがコンピュータの醍醐味でしょ

>>393
そこを設計でうまく切り分けて取り扱うのがプログラマーじゃね？

LLVM CodeGen はともかく、Analysis/Transformations(いわゆるopt)は
TargetData すなわち語長とかアライメントにすごく依存している。
TargetData を取り去って最適化をかけようとしてもロクな結果が得られない。

sizeof, offsetof とかは、バックエンド的には gep NULL / ptrtoint を吐いとけば十分で
あとはInstCombineとかConstantPropあたりがTargetDataに即した数字にしてくれる。

int f(int n) {
int a[n];
return sizeof(a)/sizeof(int);
}

>>395
char buf[sizeof(struct t)] とかやることを考えたら、結局フロントエンドでも把握してないといけないわけで、
フロントエンドとバックエンドが別々にサイズ足してアライメント考慮して……ってやるのはバグの元だし
やっぱりクロスプラットフォーム投げ捨ててるし、もうちょい上手い方法が欲しいけどなあ……

フロントエンドが決めずに誰が決めるんだよw

CやC++の仕様(intのサイズは実装任せ)と
処理系の実装の話を混同してないか?
処理系はいつもサイズを決めてる。
アラインメントも決めてる。

「決まらない」のはあるソースに対して、
処理系を変えた場合。

フロントエンドがstruct {char x; int y}のサイズを計算した値と
LLVM側が{ i8, i32 }のサイズを計算した値が一致する保証はないよね、怖いね、って話だよ

合うように{ i32, i32 }にしてるっしょ?

春先まで {[8 x i8]} だったわけだがw

TDの扱いについては clang と llvm でコンセンサスはとれてる。

保守

c"……" っていう文字列定数の記法がリファレンスに載ってないような

>>403
llvmdev にて突っ込んでくれるとだれか若干名が修正してくれるかも。
俺は英文ドキュメントいじるのが億劫なのでパス。

Windows用のフリーコンパイラってCygwinとかBCC(まだある？)とか簡単に使えるのが無いんだよね
clangが他に依存せず容易に使えるフリーコンパイラになってくれるとうれしい

VCのCLがダメな理由ってなんだろう・・・。

登録が必要じゃん
あとライセンスとかどうなんだか

CL自体はWindowsSDKにも入ってたと思うので登録は必須ではないかも。
ライセンスは、おかしな事しなければ引っかからないと思うけど、なにしようとしてるんだろう。。。

別に何もしようとしてないよ？
ただ「フリーソフトのみ無料でOKだけど商用利用は駄目」とか色々あるから
そういう面倒な事が無いのがいいだけ

ライセンス読む気がないなら諦めろ

禿同

GCC(MinGW)でいいだろ
ClangがWindowsにきちんと対応するのはまだまだ先だろうし

GPLより修正BSDライセンスのほうが良いとおもっただけです
あとMinGWとかCygwinは大掛かりというか環境を汚しそうで…
本気で作るならVSなりIntelCなり買うべきなんでしょうが気軽に試せるのがないなあと
以前は雑誌付録のBCCが良い感じだったのに最近は登録（今もやってるかは知らん）になったし
また「商用駄目」ライセンスとか不便だろうしって「新しいモノ」に期待してるだけです

＞MinGWが環境を汚す
アホすぎ

空白入りパス(要はProgram Files)以下に配置できないから、ルートディレクトリ以下に
直接置かないといけないって意味では環境汚すよな＞mingw

>>413
おまえコンパイラ自体をいじる気か?

>>415
Users 配下でいいじゃん。
…ユーザ名に半角空白を含ませてるヤツは首を吊れ(実例多数)

GPLでんでん言ってるアホは、M$FTの製品使ってEULAに汚染されるがよい。

>>415
データドライブにでも入れとけ

VCEE2008 は用途の縛りはなかった。登録も必須でないから無視したらいい。
Cygwin は滅茶苦茶簡単でしょ。llvm がこれより簡単になるとは思えない。

CLつうかMS Optiomize Compilerは、LLVM使えんがな

>>413
使った事もなくドキュメントも読まず想像だけでよくそこまで適当なことを書けるな……
>「新しいモノ」に期待してるだけです

お前一生「期待してるだけ」「待ってるだけ」で終わるよ
自分で結局何もしないんだから

みんなわかってて黙ってるのにわざわざ教えちゃうなんて興のないことを。

3.0rc2で盛り上がってるのかと思ったら全然違った

ふつーリリースブランチは盛り下がるもの。

16日（実質17日？）まではここも過疎だろうな

>>415
リンク張ればどうにでもならないか？
いつもopt->Program Filesでリンク張って、mingwはc:\opt\mingwだけど。

そういえばNTFSにはリンクがあったな

clang ドライバの Linux 各種ディストロ向けクリナップに勤しんだあとRC3に突入する予定の模様。

clang用にautotoolsをどう設定したらいいのか解からん。
autotoolsって実質gcc専用？

CC とかを設定してあげればいいのかな。

今は手を出さずに、>>425まで待ったらいい
仕様が色々と大化けするみたいだから

GCCと同じ流れ（.oを出力→.oを外部ライブラリとリンク）なら、CCとCXXを変えるだけでそれなりに動く
もちろん、language compatibilityに引っかかるようなコードは修正が必要だし
Clangが対応してない特殊なGCCオプションを使っている場合は
makeの時に*FLAGSを書き換えるかMakefileにパッチを当てる必要がある

.bcを介したLLVM/Clangツールチェーンでのビルドは結構難しいと思う
http://tribelet.blogspot.com/
ここの「透過的なLLVM」ってタイトルのシリーズがそういう実験をしてる
少し古いから、今のLLVMだともっと簡単かもしれないが……

>>432
>.bcを介したLLVM/Clangツールチェーンでのビルドは結構難しいと思う

clang -O4 は -O3 -emit-llvm と同じ意味なので、 (*.o の名前で bc を吐く)
リンカを gold とか apple linker など、llvm lto対応のものを用いることができれば難易度はぐっと下がるとオモ。

binutils とか libtool が絡んでくるととたんに難易度があがる、つかもう手作業。

いいかお前ら、リリース云々とかに惑わされるなよ?
常に tip of trunk を使え。 ToT

もう1ラウンドやるのか

こんにちはそして30日にまた合おうノシ

ものすごい初歩的な質問で申し訳ないんだがビルドして
make check-allした時にUnexpected Failuresが出なければビルド成功でいいんだっけ？
Scientific Linux 5のx86_64の環境で俺が出した結果がこれなんだけど…

Testing Time: 68.05s
Expected Passes : 5496
Expected Failures : 50
Unsupported Tests : 16

ok. clang を含んでないなら check と check-all は同様。

failure もしくは unresolved が現れたら make check はエラー扱いするので
$ make check VERBOSE=1 && echo OKOK
でもやってみなはれ。

RHEL5 クローンだったら make check LIT_ARGS='-sv -j32' とかやってみるといい。

3.0 (´∀｀∩)↑age↑

3.1ﾏﾀﾞｧ-? （･∀･ ）っ/凵⌒☆ﾁﾝﾁﾝ

3.1 (´∀｀∩)↑age↑

下げてるじゃねーかw

LLVMの構文についての質問なんだけど、
あるLLVM-IRのファイルから、
他のLLVM-IRのファイルを読み込む方法ってある？

C言語でいう
#include "foo.h";
みたいなの。

初心者の質問ですまん。

ない。

ぶっちゃげ言うと IR の .ll (表示形式)はあくまでもダンプ用。ついでにいうと Bitcode もダンプ用。
LLVM API であれこれいじりまわすのが本来の使い方。

includeはないがllvm-linkでbitcodeをくっつけることはできる

thx

llvm-linkでくっつける方法もあるのね。
llvm-linkでくっつける際に名前が重複してた場合って、
勝手に置き換わったりしますか？

gccで出来るような各オプティマイズレベルで有効になる最適化
オプションを出力するみたいな事をllvmで出来ますか？
Q オプションみたいなの。
例えばclang -O3 でどのようなオプティマイズオプションが効いているのか
を表示したりしたいんですが。

>>447
+Asserts ビルドだったら -mllvm -debug-pass=XXX とかが使える。

あとは
llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
clang/lib/CodeGen/BackendUtil.cpp
あたりを眺めてくれ。

>>448
ありがとう！

質問があります。
ttp://clang.llvm.org/get_started.html
ここを見て、
「../llvm/configure --enable-optimized」
「make ENABLE_OPTIMIZED=1」
まで終わらせたのですがC++の機能が正常に動作しません。

工程6の
「'gcc -v -x c++ /dev/null -fsyntax-only' to get the path.」
「Look for the comment "FIXME: temporary hack: hard-coded paths"
　in clang/lib/Frontend/InitHeaderSearch.cpp and change the lines below to include that path.」
で具体的に何をすればいいのか分かりません。
恐らく「gcc -v -x c++ /dev/null -fsyntax-only」でパスを取得して（どのパスか分からず…）
「llvm\tools\clang\lib\Frontend」を改変した後（どう改変すればいいのか分からず…）に
もう一度「../llvm/configure --enable-optimized」「make ENABLE_OPTIMIZED=1」
をすれば良いのかと思いますが、make中にエラーが発生してしまいます。

どなたかご教示ください。

訳もわからずコマンドっぽいことだけそのまま実行するんじゃなくて、ちゃんと文章を読もう。

>>450
MSYS Mingw か?
まずは現状ママで make して clang++ -v blahblah.cc -c とかでインクルードパスをチェックするよろし。
で、出てくるサーチパスがチミの環境に合致してなかったらはじめて InitHeaderSearch.cpp をいじるクル〜

msys もしくは mingw だったら configure じゃなく cmake 使ったほうがいいよ。
(CMAKE_BUILD_TYPE=Release を忘れぬよう)

なお、 configure で --enable-optimized を指定した場合、 make ENABLE_OPTIMIZED=1 は不要。
生成された Makefile.config を参照のこと。

>>450
マルチすんな

マルチポストしてすみませんでした。

マルチポスト、クロスポストなんてネットニュースの時代の前世紀の遺物だ。
リソースが豊富な現代では無問題。

それはひょっとしてギャグでry

対応する人間のリソースは無限じゃねーよボケ

まぁ実際たいして害もないし、ただの慣習だとは思うが

clang 3.1 mingw32 セルフホスティングできた
toolchainあたりはそこまで複雑ではない感じ
リンク時にgccじゃなくてldを呼ぶのは難しくないような気がする

実行ファイルにせずlliで実行したらどんな感じだろ
まだ遅いかな

Java VMとLLVMって具体的に何が違うの？

LLVMはRISCライクの命令セットで既存CPUのネイティブコードに近く
各CPUのネイティブコードに変換しやすくなってる
開発者の環境で、中間コードからネイティブコードを作るのが主なお仕事

JavaVMはLLVMより抽象度が高めでGCも持ってる
高速化のためJITを持ってるけど
ユーザーの環境で、中間コードを動かすのが主なお仕事

文の区切りがあれなので句点を補足
>変換しやすくなってる。
>GCも持ってる。

LLVM はもはや Low Level Virtual Machine の略でもなにかの略語でもないって Chris が言ってた。
ていうかもはや Clang のバックエンドに成り下がってるし。

そしてldcのバックエンドでもある、と

ghcのバックエンドでもある

LLVMはClangの都合に振り回されてるってば

もうclangでいいんじゃね？ｗ

LLVMが注目されだしたのclangのおかげ

pythonでも使えたろ

pypyだっけ

llvm-pyだな

Clang (C family)
Lightspark (ActionScript)
PyPy (Python subset)
Rubinius (Ruby)
Emscripten (C++ to JavaScript translator)
GNU lightning (Multi-plutform assembly)

GHC

DHC

DHA

DNA

New package: llvm/clang-3.1-1
http://cygwin.com/ml/cygwin-announce/2012-07/msg00007.html

「AIR for iOS」はLLVMの技術で実現している
http://www.atmarkit.co.jp/fsmart/articles/air_int/01.html

AdobeはLLVMにベッタリやなぁ
対.net Framework包囲網としてApple/Google/Adobeが
結託してくれりゃいいのに。

DelphiのバックエンドもLLVMになるようだな

エンバカデロってC++は既存のコンパイラー捨ててclang使う気らしいとか聞いたな

俺の肛門様もLLVMに(違

>>478
Cygwin のって、なんか特異なパッチ当ててたっけ?
俺的には、おまじない LDFLAGS=-static くらいか。

>>481
ボーランドのコンパイラもついに消滅か

>>479
そもそも、gccにベッタリした企業なんてあるのか?

llvmはclangがgccの対抗ってことになってるけどね

もともとFSFかLinux周辺のGPL推進してるところだとあるのかな？
BSD陣営はもともとコピーレフトじゃないツール求めてるし。
そういえば、GCCの高速化や新命令セット対応はRHの人たちがやってるのだろうか？それともCPUメーカーやハードメーカーでやってるのか、その他の有志なのか。

>>486
gccのmlのlog漁ってみりゃいいじゃん

Linux、gccだったらIBMの貢献も大きいイメージあるな

clang/llvm の予算つぎ込み度合い http://sylvestre.ledru.info/blog/sylvestre/2012/07/22/who_is_in_control_of_llvm_clang
AAPL さすがですね。 GOOG もなかなかなもんです。

Apple, Google, ARM, Intel, Nvidia, AMD, MIPS, ついでに Qualcomm(QUIC, CAF) が
それなりに協調してやってるあたり、ある意味感心する。
MLをヲチしてる限り、Microsoft とか Samsung を見かける頻度は稀。Redhat もなかなか見ない。
SCEAはちょくちょく見かけるが、一見貢献ナシ。

注目は PathScale ですw

llvmはgccと違う最適化をやろうとしてるからね

からあげ

チュートリアルやろうとして、とりあえずコピペでコンパイルしたらエラーになる。
http://llvm.org/releases/3.1/docs/tutorial/LangImpl3.html

$ clang++ -g -O3 toy.cpp `llvm-config --cppflags --ldflags --libs core` -o toy
toy.cpp:401:18: error: no matching member function for call to 'CreateCall'
return Builder.CreateCall(CalleeF, ArgsV, "calltmp");
~~~~~~~~^~~~~~~~~~
どうすりゃいいの？

昨日食ったからあげで腹壊した

>toy.cpp:401:18: error: no matching member function for call to 'CreateCall'
え、これが読めないとか？
clangは構文チェックが半端じゃないみたいだね
みんな、泣いてる？

>>492
3.2 では治ってる予定。

llvm/examples/Kaleidoscope/Chapter3/toy.cpp
こっちが大元。

>>495
たしかにtrunkにあるファイルだと該当部分が変更されてる。
面倒なので大人しくXCodeのllvmが3.2になるの待つわw

宣伝がすごいけど、実はまだ大したレベルではないみたいだな

>>486
gccはAMDが結構改良してる

2008年のデータ
http://www.sdtimes.com/link/32870
Software development tools company CodeSourcery leads the list of corporate contributors to the GCC.

Red Hat, IBM, Novell, Google, Intel and AMD rounded out the GCC corporate contributors top ten list, in that order.

パッチの量とパフォーマンスの大幅な改良やクリティカルなバグ修正などとは比例しないかもしれないが。

GCC git stat
http://www.phoronix.com/scan.php?page=news_item&px=MTE1OTg
LLVM git stat
http://www.phoronix.com/scan.php?page=news_item&px=MTE2MDk

githubとか言われてる割に
鯖が貧弱なところが多いみたいだけど

llvmのフルビルドは昔のgcc並に時間がかかる

clang+llvmフルビルドで5分

どういう環境だ？
make clean
やってみたら

- AMD FX 8150, 32GB RAM, Intel X25-M
- make -j8
- コンパイラは Release-Asserts でビルドした clang
- make clean どころか configure(16s) から

これで 5:33
あ、ごめん、configure まで入れると6分近いな。

cmake+ninja (-j24) で 3分切るようだ。

それ。llvmだけじゃあ

apple主導の技術は例外なくコケる
成果はあるんだからはよgoogleなりmsなり動けよと

>>508
>apple主導の技術は例外なくコケる
具体的にくわしく

OpenDoc

もっと新しい技術で

WebKitを使ったブラウザにTrueType表示された物を読み、手前にトラッキング
デバイスが配置されたノート機からUnicodeで書き込む>>508であった。

ハード規格はぱっとせんな。火縄とさんぼるが面白いくらい滑ってる
ソフトだとロジックもFCPも停滞してるが、湧かせた事があるだけマシか

LLVMは今Appleが手を引いたら寒くなるんじゃ

気を取り直してハードに限定しました☆

いえい

りんごでしかもの見てない人たち？

>>508
GOOG の貢献率は2番手。 Sanitizer は Google Moskva の成果。

AAPL主導の云々は ObjC 周りくらいじゃないか?

ttp://lists.cs.uiuc.edu/pipermail/llvmdev/2012-November/055494.html

ttp://lists.cs.uiuc.edu/pipermail/llvmdev/2012-November/055574.html

LLVM 3.2 is Here.
http://llvm.org/docs/ReleaseNotes.html

cygwinのclangとフルビルドについて質問です。
現在cygwinにバンドルされているのはclang-3.1-3ですが
最新版が試したかったのでリポジトリからtrunkを取得してビルドしてみました。
しかし過去ログにあるように
>>349
>Cygwinでビルドした clang.exe が起動激遅。clang --helpですら1秒くらい時間を要する。
という同じ状況になりました。
バンドル版は高速起動です。
time clang -cc1 -version
で計測して比較してみるとかなり差があります。
特に２回目以降の起動で大きな差がでます。

当初はtrunkのclang-3.3が重いのかもしれないと思い
バンドル版と同じバージョンの clang-3.1
llvm.org/svn/llvm-project/llvm/tags/RELEASE_31/final
を取得して
CC=gcc CXX=g++ ../llvm/configure --enable-optimized --enable-assertions=no --enable-targets=host-only --enable-shared
でビルドしましたがやっぱり自分でビルドしたバージョンは激おそです。
ビルドしたものはmake install せずにその場で実行しています。

時間比較は以下でしました。
# ビルド版
time ./Release/bin/clang -cc1 -version
time ./Release/bin/clang -cc1 -version
# バンドル版
time clang -cc1 -version
time clang -cc1 -version

バンドル版を同じぐらいの実行速度を出すにはどうしたらいいんでしょうか？

パッケージのソースからビルドを試さないとなんとも言えんな。俺が知ってる回避策は LIBS=-static

>>349 は俺。引き続き准教授とか待ってる。

$ make VERBOSE=1 REQUIRES_RTTI=1 OPTIMIZE_OPTION="-g -O2 -fomit-frame-pointer"

helpすら遅いって明らかに何かおかしい
アンチウイルスを止めてみたらどうかね？

ビルドログを見て
最適化フラグが期待通りになってるか確認すれ

1. 最適化についての確認
ビルドログを確認してO3であることを確認しました。
また、
time ./Release/bin/clang -cc1 -version
の実行結果が
LLVM version 3.3svn
Optimized build.
Built Feb 14 2013 (12:11:02).
Default target: i386-pc-cygwin
Host CPU: core-avx-i
となり、最適化されていることがわかります。

2. パッケージのソースからビルドを試さないとなんとも言えんな。俺が知ってる回避策は LIBS=-static
LIBSは make 引数？ configure前引数のどちらでしょう？
configure の --enable-embed-stdcxx=yes と同等ではない？
ちなみに --enable-shared --enable-embed-stdcxx を同時指定して作成された makefile だと
ビルド後半でリンクエラー終了（うろおぼえ）してました。

3. $ make VERBOSE=1 REQUIRES_RTTI=1 OPTIMIZE_OPTION="-g -O2 -fomit-frame-pointer"
これも結果変わりませんでした。

4. アンチウイルスを止めてみたらどうかね？
とめました。また、アンチウィルスのせいだった場合cygwinバンドル版も遅くなるきがするのですが・・。

5. cygwinバンドル版3.1-3ソース
とりあえず落として中身を見ました。 ./llvm-3.1-3-src/llvm.cygport
内にconfigureオプションの記述がありました。
cygconf --disable-assertions --enable-optimized --enable-debug-runtime \
--enable-debug-symbols --enable-targets=all \
--enable-libffi --enable-shared --disable-embed-stdcxx \
--with-gcc-toolchain=/usr
見てる限り大体同じような感じでした。 あれ？シンボル込み？？ってところ意外は。

6. cygwinバンドル版のバージョン番号の意味
3.1の 1-1,1-2,1-3って何が更新されてるんだろう？？
diffとってもこんな感じだし・・

diff -r llvm-3.1-2-src/llvm.cygport llvm-3.1-3-src/llvm.cygport
5c5
< RELEASE=2
---
> RELEASE=3

つーかバージョン番号進めてるだけやん。
っていうのとcygwinでの3.2リリースってどこかにアナウスされてますかね？
バンドル版3.2がリリースされて軽快な動作なら、そっち使うんですが・・・。

clangがbinにあるとclangでコンパイルするみたいだけど、llvmとその一族

>>529
3.1-3はCygwinのPythonが2.7系へ変更されたためのリビルド
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/llvm;a=commit;h=7b781158fdd956e35fcdfd4057e8cb10f4259387
Cygwinの3.2はまだ出てない

>>528
strace でなんか見えない？

見捨てられたCBackendが別の人に拾われて復活していた

面白そうなので上げます

>>533
mjdk!

JavaScriptバックエンドを作りたい人がベースにしようとしてGitHubに入れていたが
JavaScript版は放置されていた

CBackendは一応２〜3ヶ月前のLLVMなら動く
API変更があったため
リポジトリの最新版のLLVMでは色々手直ししないとだめぽ

GitHubにあるllvm-mirrorのフォークではないらしく
ローカルリポジトリの同期先に追加しようとしたら共通コミットが無かった

>>536
>GitHubにあるllvm-mirrorのフォークではないらしく

https://github.com/earl/llvm-mirror
NOTE: The LLVM project now operates official Git mirrors as well: http://llvm.org/docs/GettingStarted.html#git_mirror -- An
automated mirror of llvm/trunk from LLVM's SVN. Updates hourly. Release branches and tags are tracked manually. This mirror is
*not* commit-ID compatible with the official Git mirrors.

歴史的理由がなければ earl のリポ使うんじゃない。
※earl を dis ってるのではないので念のため。

本家ドキュメントに書いてあるGitミラーのフォークでも
GitHubにあるミラーのフォークでもなかった
スマソ

CYGWINに入ってるclangとsvnでとったclangを共存させるには、どうしたらいいですか？configure --prefix=
で設定して、PATHの先頭に置けば大丈夫ですかね。
出来れば環境変数の設定だけできりかえたいので。切り替え中は実行ファイルだけでなくLIBやincludeも新しいほうをみてほしいです。

去年の夏にC++ Primer 5ed.がC++11で書き換えられていたのね。
Cは完全に排除した大幅書き換えらしい。
http://www.amazon.com/gp/product/0321714113/

おお、>>540は誤爆です...

スレタイがラブラブバーチャルマシンに見えた
禿本も新版もうすぐ出るね

>>540-541
びみょーにスレ違いじゃないとも言えなくもない。

stack overflow

memory exhausted

exc_bad_access

intelコンパイラとドッチが速い？

http://attractivechaos.github.io/plb/
http://www.ospn.jp/osc2009-fukuoka/OSC2009_Fukuoka_ComputingInJava.pdf
こんなんあるよ。

>>548
> http://www.ospn.jp/osc2009-fukuoka/OSC2009_Fukuoka_ComputingInJava.pdf
この実験結果から"LLVMは、かなり速い"は無理あるような気がするが。
あと比較対象がJAVAのAOTなのもどうかと。

「JavaバックエンドとしてのLLVM」と、iccを比較しても>>547への回答になってない気がするが。
clangと比較しろよ。

visual studio でclang3.2と3.3ビルド成功した人いませんか？
win32,x64共に３プロジェクトだけエラーになります。
stdbool.hが無いといわれてるのが９割なんですが、これってどうやって解決していますか？

後もうひとつなんですが llvm-config.exeを作成するプロジェクトそのものが見つからないのですが・・
これってどうなってるか御存知のかたいます？

>>551
llvm-config の生成はわりとくだらない理由により抑制されている。
llvm/tools/CMakeLists.txt いじって試してみてくれ。

Visual Studio, CMake, あと Python のバージョンを教えれ。

俺が知る限りビルドはふつーに行われている。
MSC16(VS2010) x64 ttp://bb.pgr.jp/builders/cmake-clang-x64-msc16-R
MSC17(VS2012) x86 ttp://bb.pgr.jp/builders/ninja-clang-i686-msc17-R

>>552
> >>551
> llvm-config の生成はわりとくだらない理由により抑制されている。
> llvm/tools/CMakeLists.txt いじって試してみてくれ。
了解です。
>
> 俺が知る限りビルドはふつーに行われている。
> MSC16(VS2010) x64 ttp://bb.pgr.jp/builders/cmake-clang-x64-msc16-R
> MSC17(VS2012) x86 ttp://bb.pgr.jp/builders/ninja-clang-i686-msc17-R
こんなビルドボットサーバーあったんですね。
知らなかった・・・。

> Visual Studio, CMake, あと Python のバージョンを教えれ。
>
VS 2010 Professional + VS SP1 + その他パッチ
Python 2.7.5 Windows X86-64 Installer
cmake-2.8.10.2-win32-x86.zipの cmake-gui.exe で作成。
※cygwin bundle のcmake.exeとofficial のcmakeを./configureして作ったcmake.exeは
　ジェネレーターにVS系が全然無いんですが
　cmake-2.8.10.2-win32-x86.zip添付のcmake.exeにはありました。これはなんで・・？

とりあえずclang-3.2 release finalでの報告。
llvm/lib/TableGen/TGParser.cpp
llvm/utils/TableGen/CodeGenRegisters.cpp
の２ファイルにパッチを当てないとcl.exeがインターナルエラーで落ちるのでこれはパッチを当てて回避してます。

パッチ適用後は上記書き込みのとおり３プロジェクトのエラーのみになります。
エラー内容は以下のみです。

6>c:\cygwin20121103\tmp\clang-32\llvm\projects\compiler-rt\lib\int_lib.h(37): fatal error C1083: include ファイルを開けません。'stdbool.h': No such file or directory
あとは
6>c:\cygwin20121103\tmp\clang-32\llvm\projects\compiler-rt\lib\int_util.h(27): error C2061: 構文エラー : 識別子 '__attribute__'
6>c:\cygwin20121103\tmp\clang-32\llvm\projects\compiler-rt\lib\int_util.h(27): error C2059: 構文エラー : ';'
6>c:\cygwin20121103\tmp\clang-32\llvm\projects\compiler-rt\lib\int_util.h(27): error C2182: 'noreturn' : 'void' 型が不適切に使用されています。

compiler-rt は対応してないと考えといて。

>>555
> compiler-rt は対応してないと考えといて。
わかりました。

いい忘れましたが上の件は3.2, trunk revision 182484で同様の結果でした。
※trunkのほうはインターナルエラーはでなかったのでパッチは当ててません。
※目的とするclang.exe,libclang.dll,libclang.libなどは得られているのでとりあえずおｋ。

ついでに他の環境でのビルドも聞きたいです。教えてください。
当方としては、32/64bit両方のclang.exeとlibclang.dllが欲しい状態です。

cygwinでx86に対するビルドは問題なく完了するのですが
x86_64に対しては--enable-targetsで指定してもhostと同じものしかみていないのか
完成するものはx86のみになってしまいます。

configure引数は↓のとおりです。

CC_CMD="${CCACHE_CMD}gcc"
CXX_CMD="${CCACHE_CMD}g++"
CC=${CC_CMD} CXX=${CXX_CMD} ../llvm/configure --enable-optimized --enable-assertions=no --enable-targets=x86,x86_64

CC_CMD,CXX_CMDを
x86_64-pc-cygwin-gcc
x86_64-pc-cygwin-g++
などにしてみましたがconfigureは途中までしか逝きませんでした。

また、mingwでのビルドを行う場合、mingw環境のセットアップと同環境でのビルドでないとだめでしょうか？
cygwinにmingwパッケージx86_64-w64-mingw32-gccなどがあるので、こちらでできれば、これらを使用してビルドしたいのですが・・。

3.3出すのにえらく時間かかってるね?

svnから3.3リリースとれたよ？

タグつけたのにリリース出すのに手間取ってるねということさ

3.2の時もタグついてから正式リリースアナウンスまでが長かった希ガス

3.2のときは短かった

昨日の朝の時点でここまでは用意されてた。
http://llvm.org/releases/download.html#3.3

おっ！ ついにLLVMの日本語技術解説本きたな
http://motipizza.com/img/eb-kitsune.jpg

>>564
なんだ、ネタかよ('A`)と思ったらネタじゃなかったｗ
それにしても、なんだこの表紙？

同人のようだな。かなり欲しいんだけど。
狐本と自称してるようだ。

ごめん、勘違いだ。インプレス出版なんだな。
これはアマゾンさんにお願いするしか無いな。

とらのあな委託かと思った

>>568
俺も。一瞬諦めかけたぜ。

それダウンロード販売もしてるよ。手許にPDFがある

それって推敲途中版じゃなかったか

>>570
萌えテイストは表紙だけ……だろうな？

ttp://tatsu-zine.com/books/llvm

久しぶりにログインしたらver. 0.9.1だった。紙の本はここから何か進展があったんだろうか。

ttp://d.hatena.ne.jp/tatsu-zine/20130621/1371811774
「電子の方の更新も近々行う予定です。少々お待ちください。」
だそうです。

>>572
表紙だけ。>>573で中が一部読めますよ。

>>574
サンクス
ぽちった
カバーは速攻ひっぺがす

そして枕の下に敷いて寝ます

数日前本屋でも平積みにしてあった
まえがきに達人出版会についても触れていたけど
ニッチな本がこうして日の目を見るのはいいことだ

エッチな本かと思た

>>574
575だが、今日届いた
カバーの下に同じイラストがモノクロで…なんて悪夢を想像したが
全然そんなことはなかったぜ

所々にはさまってる挿絵が…

表紙にも挿絵にも作者達の想いが詰まっている。温かく迎えましょう

キツネさんをamazonで注文した。楽しみだな〜。
すでにコンビニ行ってきたぜ。

>>579
>作者達の想いが詰まっている

うげ…気持ち悪い…

あなたには読まない自由はいくらでもあるんですよ？

clangって速くなった？

何に比べて？

ターゲットマシンをjavavmにしてjsをjavaバイトコードにコンパイルすると速さ競える？

>>585
javavm?そのようなターゲットは無い
前はあったらしいが

>>564
技術書までラノベ調の流れか

オレ批評してやったぜ（ｷﾘｯ

きつねさんでもわかるLLVM ~コンパイラを自作するためのガイドブック~:Amazon.co.jp:本
http://www.amazon.co.jp/gp/aw/d/4844334158/ref=redir_mdp_mobile

レビューを見る限りでは買い！とはあまり思えないが
日本語での情報がほしい人なら少しは価値があるのやもしれぬ

サンキュ！

馬鹿でもインストールできるようにしてくれないかな。。。

ディストロのパッケージでも利用すれ。

FreeBSD10からCLANG(LLVM)が標準搭載になる

というか俺はGCCを捨てるぞォォォォォッってことだろ

GCCじゃないとコンパイル通らないものはどうする

焚書

ちょっと皆の知恵を貸してほしい。

OS：Windows7 Ultimate 64bit
コンパイラ：MinGW-w64 gcc 4.8.1 dwarf2 32bit

上記の環境でLLVM + Clang 3.3をビルドして、試しに

(ファイル名：1.cpp)
#include <iostream>
int main(void)
{
std::cout << "Hello,World." << std::endl;
return 0;
}

を、MSYS上から
clang -o 1.exe 1.cpp -lstdc++
でコンパイルしてみた。

コンパイルはエラー無く通って実行ファイルは生成できたんだが、
実行時に下記画像のようになる。

http://uploda.cc/img/img5220d57c5c73b.png

VirtualBoxに構築したWindows XP 32bitでこのファイルを実行した場合には
この症状が出ないので、十中八九開発側の環境のせいだと思うんだが、原因がわからない。
例外コードやMinGW-w64 llvm関連の検索はしてみたが、俺には見つけられなかった。
同じような症状が出て、解決した人がいたらぜひ教えて下さい。

mingw固有の関数を使っているとOSがウイルス？と判定してる感じだけど

まあ、wingw自体、動作が保証されてないけどね
ウィンドウズではcygwinだけしか動作が保証されてない
要は使えないものだってことだけど

ついでに言うと、32bitプログラムしか動作保証もされてない

単なる DLL hell なんじゃないの

>>597
例外コード
ttp://www.tenox.net/links/ntstatus.html

その画面を下にスクロールすると例外のあったアドレスが出てないか？
それでぐぐるとか。共有libに戻った所で起きてるんだろうから、どうせみんな同じアドレスでじゃないのか。知ったところで解決手段は出てこないけどね

>>597
>>601が言ってるけど
libstdc++-6.dllは同じ名前でABIが違う（非互換）なのがゴロゴロしてるから
思いっきりDLL hellだと思うぞ
libstdc++をstaticリンクしてしまうか、開発側のlibstdc++-6.dllを
exeと同じディレクトリに置いた形で配布

スタティックリンクでも試してみた。
コマンドラインは
clang -static -o 1.exe 1.cpp

実行結果は以前と変わらずAPPCRASHだった。

問題の署名:
問題イベント名: APPCRASH
アプリケーション名: 1.exe
アプリケーションのバージョン: 0.0.0.0
アプリケーションのタイムスタンプ: 522176ca
障害モジュールの名前: 1.exe
障害モジュールのバージョン: 0.0.0.0
障害モジュールのタイムスタンプ: 522176ca
例外コード: c0000005
例外オフセット: 00069fa5
OS バージョン: 6.1.7601.2.1.0.256.1
ロケール ID: 1041
追加情報 1: 0a9e
追加情報 2: 0a9e372d3b4ad19135b953a78882e789
追加情報 3: 0a9e
追加情報 4: 0a9e372d3b4ad19135b953a78882e789

あと、情報が後出しになってしまって申し訳なかったのだが、XPは
開発環境自体入れていない素の状態だったので、XP上で実行時には
開発環境のlibstdc++-6.dllおよびlibgcc_s_dw2-1.dllは実行ファイルと同じ
ディレクトリにコピーしていた。

ダメだ…俺にはお手上げだぁ…潔く諦めて対応されるまで待つ。
みんな協力ありがとうございました。

>>595
標準搭載なだけでgccを捨てるんじゃないんじゃね？

ライセンスが気に入らないと言ってるから
使えなくなるのは時間の問題

使いたければ自分で入れればいいだけなので実害はなかろ

今しがた1時間程かけてビルド完了したんだけど、clang++でリンク時、_Unwind_Resume
が不明とのエラーが出ちゃう
GCCのライブラリはstaticでビルド、ってのは関係ないと思うんだけど、もうさっぱり原因
が分かりませぬ、誰かぽけすて

んでもコンパイルは出来るのでいくつかやってみたけど、GCCでは問題なくビルド出来る
ヤツでもclangじゃエラーで止まるのが結構あるね。噂どおり、ビルドの速度は速いし、
出来たブツのファイルサイズは小さくなってる

事故解決しますた
-fno-exceptionsをつけるといいみたい。
参考URL
ttp://stackoverflow.com/questions/329059/what-is-gxx-personality-v0-for

野良ビルドするのにmingwって苦行だな、pythonもパッチ当てなきゃまともに動かないし

>>557
x86_64-w64-mingw32のバイナリが欲しいって事だと思うんだけど、
3.3だとbuildとhostをx86_64-w64-mingw32にしたら作れたな

mingw32-w64ビルドのチラ裏：
cxx11を有効にしてビルドしようとすると、mingw32-ｗ64のmath.hに問題があるので修
正しないと通らない。恐らくmingw32だと通る。
面倒なので一時的に55、58、71、217、225、246、247,256行目をコメントアウトする。

検索パスはベタ書きなので、自分の環境に合わせてInitHeaderSearch.cppを書き換え

libcppはlibcxxを導入してからビルド、これもstdio.hに問題があるので修正
しかしg++が"-stdlib=libc++なんてコマンド知らん"と文句言うトコだけ解決できない。

_Unwind_Resumeは例外用のランタイム関数だぞ
-fno-exceptionsは例外を受け取れなくなるが、わかっててやってるよね？

GCCをsjlj有効にしてビルドしちゃった
なのでunwind_sjlj_Resumeはあるけどunwind_Resumeなんて知らねーよってエラー
どーしよー

libclang使ってる人いませんか？

使いたいけどまだIDE側が整ってないような

IDE側って？
libclang.aリンクして自分でアプリ作るって意味じゃないのかな

これwindowsというかmingw32-w64だと、sjljにしかregister_frameが無いから
sjlj有効にしたgccじゃないとコンパイル出来ないんだな。

でもclang側には_Unwind_Resumeはあっても_Unwind_sjlj_Resumeは無いから
-fno-exceptionsを付けないとc++のリンクが通らない。
現状win+mingwじゃ使い物にならん。公式で配布されてるのを使うしかないのか

あ、64bitの話ね
win64はsjlj使わなくても強制的にregister_frame使うようにされてた

違うな
clangにも_Unwind_Sjlj_Resumeはある
だけどsljlを有効にしたstdc++に_Unwind_Resumeが無いからリンクがこける

winでClangするぞで、ここに来たけど、winではまともに動く最新Clangはないってことか。
お前らはどの環境でClangしている？　Linuxか

OSX

OpenCL コンパイラの吐いたバイトコードを llvm-dis って、それ読んでコードを最適化する作業にハマってる。

MinGW 32 bitでは3.4 trunkが使えてたけど、一昨日の
「r193255 - llvm-c/lto.h: Avoid use of bool.」 でビルド通らなくなった

>>621
リンゴか、りんごもバイナリ配布があるからな。

>>622
それ以前の3.4＋MinGW 32 bitではまともに動いていたのか！

>>623
林檎はバイナリ配布どころか標準開発環境で採用しちまってるよ
MSもなんかリクルート出してたから追従する気があるのかもしれんけど、当面期待出来なさげなのがなんともだな

FreeBSDが一番積極的に感じるけど今どうなってるのかな

そもそも中心になってclangを開発してきたのはAppleなわけで
FreeBSDもそれを採用した

ジョブズさんに感謝です

MinGWビルドでもClangのコードコンプリート機能は使えた。
秀丸に組み込んでエセインテリセンス。
いやー捗るわコレ。

>>622
参考までに、詳細教えてくれ。
stdbool.h を削った副作用？

>>628
>>622は間違いだった。陳謝。
「r193233 - Add llvm-c-test tool for testing llvm-c」だった

・llvm-c-test
-std=c99 付きでコンパイルされるから off_t が未定義になってエラー
include/llvm-c/lto.h に含まれる off_t を _off_t に書き換えて回避可能
正しい直し方がわからないので偉い人にお任せ

・tools/clang/tools/c-index-test
-std=c89 で off64_t が未定義になりエラー
MinGWの io.h をアップデート↓して回避
http://sourceforge.net/p/mingw/mingw-org-wsl/ci/4.1-dev/tree/include/io.h?diff=38a1ac5068ce24f16e15f1e166a86d3c9cdcadfe
これもあてた方がいいのかな
http://sourceforge.net/p/mingw/mingw-org-wsl/ci/4.1-dev/tree/include/unistd.h?diff=088538f717bbafc5079940f3df298172a38ec4c1

age

libclangはようわからん・・・同じような状況なのに補完されたり、されなかったり
コマンドライン版はとちゃんと動くのになあ

LLJVMっていうのがあるらしいですけど(バックエンドにJVM)
これって理屈的には、フロントエンドが存在する言語からであれば
どんな言語でもJVMで実行可能な状態にコンパイルできるってことでしょうか？

むかしLLVM C Backendがあったが、実際には使い物にならなくてメインラインから取り除かれた。
あとは分かるな？　つまりそういうことだ。

llvm派生プロジェクトvmtkってレジュメや論文はいい感じでまとまってるのに、開発停滞してるのかな...
なにがダメだったんだろうか?

OpenJDKからライブラリを持ってきたりしてJavaVMとしての機能を優先させるうちに
実行速度の追求が二の次になっちゃって訴求力が薄れちゃったの？

llvmってバイナリ可用性はあるの？無いの？
システムコールとライブラリコールはどうやって実現してるの？

ないよ

3.4のタグは、切ってあるみたいだが
もう正式リリースされたの？

3.4正式リリースされた

これってC言語にVM組み込んで
スクリプト言語みたいにできんの？

出来るがスクリプト言語使いたいだけならLuaでも使っとけ

>>595
インストーラや標準パッケージ以外に含まれることはでは排除してない。

Revision 200000
> [llvm] r200000 - DWARFContext: Fix possible memory leak since r198908.
( ﾟдﾟ )ﾐﾀﾖ

Ruby/LLVM

>>644
それRubinius

PlayStation4に採用されたと聞いて

PlayStation 4、開発にはLLVM Clang
ttp://news.mynavi.jp/news/2013/12/25/269/index.html

リンク時間が短くなるなら良いな。

ああ

リンク時間短くなっても俺らには関係なくね
あと出力されるコードの性能がよいって本当？gcc超えたの？

出力されるコードの性能なんて
ソースコードとアーキテクチャに依存するだろ
PS3はCell、PS4はx86-64だ

x86ターゲットのGCCと比べて良いという話ではないし
そもそもマイナビの記者が言ってるのはリンカ出力のことなんじゃないか？

技術的には決定的でないと断言している
少なくともコンパイラの性能は及第点ではあるんだろう

ちょっと大きなコードを開発したことあればかなり嬉しいと感じると思うんだけどなあ。
clang はコンパイルも速いし。

最適化を期待するコードのところだけgccでコンパイルして残りはclangでコンパイル、リンクすればいいんじゃね？

エラーメッセージがわかりやすいだけでもclangは嬉しい

VCががんばっていたwindowsもClangでコンパイルが普通になり、
実質clangがデファクトスタンダードになったからね。
ほかのコンパイラ使う奴はもうほとんどいないし

LLVMLinuxってプロジェクトがあるが、進捗状況はどうなの?

>>654
あわやMSがwinそのものをclangでビルドするところまでこぎつけたのかと誤読するところ
winでも普通にclang使えるようになってきたって意味ね?

そういや前MSが募ってたclang人材って結局なんだったのかな

Apple支援要員じゃないの？

>>656
>clang人材
VCをClangベースにするためだろ
その成果がClang-clだろう

これってC++パーサにも使えるの？

これってどれさ糞コテさん。LLVM本体にはないよ
お望みのもんかわからんが、「clang パーサ」でググり続けるよろし
とりあえず構文木を得る例なんかがヒットするんで、あとはお好きなように

さんきゅ

礼なら現金で

いやいや女融通してくれればいいだけのこと

VBScriptスレに桃白白って娘が居るよ。口説いたら堕ちるかもね。俺には無理だった

鞄に入れて運ぼうとした？

そんなシーンあったっけ？
木を投げて乗ったことにビックリしたことしか覚えていない
あの運動エネルギーを出せるなら、その筋力で自分で飛べよと思う暇もないほどかっこよかった

再読したくなってきた
kindleで買うかな

昨日Juliaを知り早速インストール
2012年からの新しい言語だからまだユーザーは少ない様ですがLLVMで超高速

LLVMって日本のおかげでここまでになったらしいな
実質LLVMは日本が育てたなんだろ

何情報？

俺は主にアップルのおかげだと思います。

>>669
宇宙からの電波に決まっているじゃないですか

受信ロッド折っとけ。

http://youtu.be/AFWm7_fE7Uw

日本ってオープンソースなんかへの貢献度すくないからね
日本はテイク、テイク、そして、ちょっとだけギブって感じだし

先進国の体でいながら、いろんな意味でショボイ日本
って言うかアジア圏全般にプンソへの貢献ショボイんかな

>>675
経営者がしょぼい

日本語で情報発信してもきちんと受け取れない無学な夷狄が悪い

バカは閉じこもってネトウヨでもやってればいいんじゃないかなw

>>675
日本は底辺職業のドカタ
欧米はエンジニア
ドカタじゃ貢献できないわな
ついでに社長に必要なのは人身売買のスキル

clang++が使えねー。ビルドしたのを実行すると異常終了する。
なんでだろ。。
clang version 3.4 (198054)
Target: i686-pc-mingw32
Thread model: posix

windowsでclangは使い物にならない
clang4.0くらいまで待て

clang-clでもつかってみー。

>>680
いまやデファクトスタンダードのClangが使えないって糞環境だな

Linus Torvaldsが乗り換えたらデファクトスタンダードと認めよう

誰？

windowsが落ち目？

まだ残ってたんですか？
皆さん移行しましたよ。

ねーよ

「C++フロントエンドとしてClangを使ってLLVM中間コード（IR）を生成したのち、
プロプライエタリなIntel製のコンパイラでその中間コードをネイティブコードにコンパイルする」

IntelがClangベースのC++コンパイラを開発 | スラッシュドット・ジャパン デベロッパー
http://developers.slashdot.jp/story/14/05/02/0425216/
2014年05月02日 16時03分

>>689
これすごいじゃん。
フロントエンドがなんだろうと最終的にIntelコンパイラで最速コード吐けるじゃん。

# なんか文章変。日本語難しい...

わろた

次期LLVM 3.5新機能発表 - Linux/FreeBSD Sparc64セルフホスト成功
http://news.mynavi.jp/news/2014/05/09/035/

20年くらい前のＪａｖａみたいな、
10年くらい前の.NETみたいなことじゃん結局

>>693
どゆこと？

このスレにSparc64向けのソフト開発している奴いる？

sparc v9 なら使っているけど？

気持ちは、いつもsparcしてる

良く落ちるSparc

その洗剤を買って、箱をサーバ室に置いてあるとかいうネタは「root訪問記」にあったなw

700

>>693
今度はマルチランゲージでネーティブ吐けるよ。

おっさんだらけやな……でも、SPARCはもう触ってないな……端末はあっても火が入っていない……

若い子はこんな地味な世界こないでしょ

>>702
SPARCとかR3000が主役頃のRISC Workstationの力がGL付きで手のひらに乗る時代とか想像もできんかった

LLVM/ClangはLinuxカーネルにGCC拡張多すぎて完全にコンパイル出来てないんだっけ?

GCCに依存してますね、linux kernel
同じ処理に置き換えればいいのでしょうが、clangはarch依存の。。。

LinuxがGPLライセンスを貫くのはいいが、GCC依存は解消した方がいいな。
GCCの仕様・不具合にLinux Lernelが左右されるなんて事が起こり得る。

clangがgcc依存の部分をなんとかするほうがよくね

ラッパーが頑張って何とかなるならとりあえずはいいかもしれんが、気持ち悪い
FreeBSDが実現できてるのにLinuxができてないのは面倒臭いからなんだろうなぁ

>>709
developerworksの記事に何をしてるか書いてあるから読んでみた。
ttp://www.ibm.com/developerworks/jp/linux/library/l-gcc-hacks/

これは手を付けるのイヤかも

最近こんなニュースを見たが
Linux 3.15 Can Almost Be Compiled Under LLVM's Clang
ttp://www.phoronix.com/scan.php?page=news_item&px=MTY2MjY

Can Almost

http://news.mynavi.jp/news/2014/05/15/252/
WebKit開発チームは5月13日(米国時間)、「[LLVMdev] WebKit + LLVM」において
WebKitのJavaScript処理系に新しくFTL JIT(Fourth Tier LLVM Just-In-Time Compier;
第4段階目のJITコンパイラ)と呼ばれる高速化機能をデフォルトで有効化したと伝えた。
次にリリースされるMac OS XやiOSのSafariから有効になる見通しで、
JavaScriptで開発されたWebアプリケーションの実行速度がさらに高速化するものとみられる。

chromeがforkした後でLLVM採用か
どうなるのかwktk

webkitのes6対応が出遅れてるのが気になるけど

almostって99%ぐらいは出来るってことだよな
でも1%が何万行のソースになるんだろうな

瑣末な部分を除いてというポジティブな意味なのか
これ以上はもう駄目というネガティブな意味なのか

JavaとLLVMはあまり組み合わせ的に早くならなかったみたいだけど、Javascriptだとどうなんだろうね？

量産型VMが真っ赤に塗られたVMに勝てるはずがない

プログラムで真っ赤って言うと、エラーやバグが連想されるんだが。

WebKitのJITについては、発表してる記事自体が、図入りで非常に詳しい。
https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

なので、図だけでも眺めると楽しい。

>>714
Chromeはフォークする前から、というか初めからv8使ってたはずだから、WebKitのjscoreについてはchroniumチームはもともと弄ってないはず。

>>712
まー最初の一歩なんではないかと。
その内色々縛りが厳しくなったりラッパーが充実したりでコンパイラ選ばなくなるでしょうね

Swiftスレ
http://peace.2ch.net/test/read.cgi/tech/1401736341/

VMが欲しかっただけ、Cコンパイラなんかいつでも切り捨てる気満々でしたとさ・・・。

FreeBSDはコンパイラが更新されないcc時代に逆戻りか

to be lovin' heee today

バックエンドがしっかり強化されるならそれで問題ないやん

>>713 >>717 これが入った次期iOS8 ベータバージョンではiOS7のSafariに比べて35％早くなっている。
ブラシュアップがまだ入るからもう少し早くなっていくだろう。

to bring some lovin' here today

>>720 テスト用ソースが　.c とか　.cppになってるけどCからJavascripへ変換したものでテストしたんだろうか。

>>725
VMっていうかSwiftはobj-cランタイム互換なんでそこはもともとAppleの製品では

つかc切り捨てはまず無理だろw
Apple自身もSwift最速を謳ってる訳でないし、os絡みでunsafeなコード扱うためにもc++共々お付き合いし続ける必要がある

clang、llvm共々注力し続けるんじゃないのかな
なんか甘い見方だったりすんのかな
Appleの切り捨て体質は百も承知だけど、Swiftで将来が危うくなったのってobj-cだけじゃないかと思うのだけど

いかん、書けば書くほど自信がなくなってきたぞ

注力は知らないけど llvm clang で頑張ってるのは gcc の GPL v3 に巻き込まれたくないから。
別の選択肢が出なければコミットは続ける。

Swift で objc が危ないというのは誤解。
Blocks みたいな独自拡張で止まる可能性は十分あるが、Cocoa を呼ぶのに inline Smalltalk を使うか内部がプロトタイプベースOOな別の言語を使うかというだけ。

>>725 FreeBSDのコンパイラは既にLLVMなんだけど。　OSXもね。
>>732 ObjCが危ないと言うよりは全面切り替えになるよ。　ObjC　>　Swif5tのコンバータまで用意してるんだから。
OSのすべてを切り替えるかどうかは解らないが。

最新のlinuxカーネルはLLVM/Clangでも結構コンパイル出来るようになったみたいだな。
Linuxは標準のコンパイラがLLVM/Clangに切り替わってもGPLで通すのかな。

LLVMに乗り換えることはあっても GPLを捨てることはあんめぇ

>>733
> ObjCが危ないと言うよりは全面切り替えになるよ。
なるわけねーだろ。
かなりの量を C/C++ で書いてるゲーム屋をどうするつもりなんだよ。

結構ってのは微妙な表現だね
arch（gcc?）に依存しないところはそれなりにコンパイルできるでしょ

今殆どコンパイルできるようになったと言う段階で次のバージョンからはLLVMコンパイルバージョンになるみたい。。

へーへーへー
そういうことできる人がいるんだ

>>736
これまでも何度かやってるし、切り捨てじゃないの。
まぁ、そのための移行期間とツール配布はやってくれるだろうね。

xcodeは社内専用ツールでOS開発に使用。一般人はswift使えって流れでしょう。
まえにJavaを使って画策してSunとの関係でうやむやになった感じだったから
今回はVMはLLVMで言語はSwiftと謹製で固めてきたから最後まで行くんじゃないかな。

マルチプラットフォームなソフトからハブられそうだし、そんな簡単に前面きりかえにはならんだろ。

あそこはプロセッサの仕様を定義するだけでなんでもござれやりたいんじゃない？
かつてNeXTSTEPの頃クワッドファットでやってた事をシングルコードで

>>740
なるわけねーっつの。
Cocoa を捨てる時が来たらあり得るかも知れないが、そしたら Android でいう JNI のようなもので C/C++ をサポートするだろう。

> xcodeは社内専用ツールでOS開発に使用。一般人はswift使えって流れでしょう。
社外は Swift だけとか Adobe とかにも強制するのか。
つーか Swift 書くのも Xcode だろ。

> 今回はVMはLLVMで言語はSwiftと謹製で固めてきたから最後まで行くんじゃないかな。
VM が LLVM ってなんだ？
Objctive C も iOS も知らないなら口出さないで BSD/Linux 事情だけ説明してろよ。

Swiftのツールチェーンでは、
一度、(LL)VMのbitcodeに変換されるが、
そのあと、ネイティブのマシン語に(ngenやgcj)みたいにAOTコンパイルがおこなわれる。
ARCはruntime(ライブラリ)で管理される。

これであってる？

似たような認識だけど具体的検証の方法が分からない三下ですすみません
Obj-Cのランタイムってのがそもそもどういう形でネイティブ上で動いているのかも分からない。ググっても掘り下げ方がわからない手合いです
ランタイムってそもそも性的リンクされてるのかな動的なのかな

参照回数で生き死にを管理するのはランタイムだけど、参照回数を増減するコードを生成するのはコンパイラじゃないの？

生のCoreFoundationの実装の解説でも読めばええんでないの

「WindowsがOSの機能として持ってるメッセージキューを
Obj-Cでは言語ランタイムの機能として持ってるって考えろ
メッセージを投げる対象がウィンドウではなく各クラスのインスタンスになったものだ」

って、Windowsプログラムやったことある人に言えば大体通じた

Windowメッセージに対応するのはRunLoopまわりだと思うけど

ガベージコレクタの話ならWindowsでそれらしく対応するのが無いな、まぁ。。。

>>745　LLVMのバイトコードになった後、ターゲットマシン毎に更に最適化して機械語になる。
動的か静的かと言うのは言語上や使い勝手の上から言う事であって、機械語に区別が有る訳ではない。

LLVMの最適化は何度も行われる、コンパイラ段階、機械語段階。
中間バイトコードIRはLLVMのJITで動作させることも可能。　LLDBもこれを扱う？

LLVMの最適化の概要
http://nothingcosmos.wiki.fc2.com/wiki/LLVM%E3%81%AE%E6%9C%80%E9%81%A9%E5%8C%96%E3%81%AE%E6%A6%82%E8%A6%81

「ググっても掘り下げ方がわからない」なんてレベルの奴相手には、
何を説明しても無駄だと思うけど。

>>750
んっと、llvmの最適化の話ではなくObj-Cのランタイムの扱いの話なのですが

>>745
スレチ

>>752 ObjCは単なるCの拡張だからランタイムが静的リンクじゃなくてどうする。　後の話は >>747

Obj-Cのランタイムは普通にコード公開されてるんだからそれを読めとか言っても無意味なのは言うまでもない

ダンゴは嘘や暴論を言ってから詭弁や強弁で負けなかったことにするゲームをやってる。
だからハッカーズディライトの話をしているとき以外の団子とまともに会話しようとしても無駄。
だから
「WindowsがOSの機能として持ってるメッセージキューを
Obj-Cでは言語ランタイムの機能として持ってるって考えろ
メッセージを投げる対象がウィンドウではなく各クラスのインスタンスになったものだ」
に対して、じゃあ ruby も javascript も同じだろとか言っても無駄。

誤爆した。悪くないと思ってるわけではない。

HackersDelightなんてまともに読んでないけど何か？
あんなアルゴリズム本読まなくてもスッと出てこなきゃ三流

いや読破はした。内容は覚えたから手元においておく必要は無くなった。

そもそもObjCはあくまでネイティブ言語で、メッセージキューをランタイムライブラリで処理してる
といってるだけにすぎん。
RubyやPythonみたいなもともとネイティブコードでないスクリプト言語を引き合いにだすのはアホでしかない

メソッド呼ぶのにメッセージキューなんか使ってねえよ

https://developer.apple.com/jp/devcenter/ios/library/documentation/ProgrammingWithObjectiveC.pdf

団子はCoreFoundationのRunLoopとObjective-Cのmessage dispatcherの区別も付いてないのか。

メッセージキューじゃなくてMFCのコマンドルーティングの方が近いんじゃね

>>756

javascriptとは明らかに違うだろ。
Objective-Cはこれと同じだぞ。

Object
　subclass: #Some
　instanceVariableNames: ''
　classVariableNames: ''
　poolDictionaries: ''
　category: 'Example'.

! Some class methodsFor: 'Example' !
doesNotUderstand: aMessage
　
　Transcript
　　show: aMessage selector asString;
　　cr.
!!

"Selectorとして指定したhelloをConsoleに表示する。"
Some hello.

基本的にはWindow MessageとSmalltalkやObjective-CのMessageは互換性がある。

! MyWindow methodsFor: '' !
wmCreate: aCreateStruct
　"WM_CREATE"
!
wmDestroy
　"WM_DESTROY"
!
doesNotUnderstand: aMessage
　"CallWindowProc"
　^ aMessage sendTo: defaultWindow.
!!

"CreateWindowEx"
window := MyWindow create.

"SendMessage( window, WM_DESTROY, 0, 0 );"
window wmDestroy.

Message Queueは通常の言語機能だけでは出来ないが、
Libraryと組み合わせればできる。
標準のMessage送信だけではQueueを持たないと言うのは事実。

button := Future delegate: Window create.

"PostMessage( button, WM_CLICk, 0, 0 )"
button wmClick.

シングルスレッドアパートメントモデルはキューイングしてるでしょ？
.NETやJavaなんかのUIの話になるが

いやだから誤爆して悪かったって。756　に間違いがあったとは少しも思わないが、もし続けたい人がいるなら別のスレでやろう。

Swiftの制作者 Chris Lattner は、WWDC14のキーノートでSwiftの説明をしたその人なのですが、
実は、今ではXcodeの標準コンパイラ基盤となっているLLVMを設計した人なのです！

ウェブで公開されている情報によると、イリノイ大学アーバナ・シャンペーン校でComputer ScienceのPh.D取得後、
Apple Inc.のXcode/Instrumentsのプロジェクトに入ったのが2005年。
そんなChris Lattnerが、2010年から作り始めた言語がSwiftなのです！
私たちからするとSwiftは「突然出てきた新言語」なのですが、その背景を知ると「満を持して出てきた新言語」なのです。

Chris Lattner (born 1978) is an American software developer,
best known as the primary author of the LLVM project and related projects, such as the clang compiler.
He currently works at Apple Inc. as the Director of the Developer Tools department, leading the Xcode, Instruments and compiler teams.
http://en.wikipedia.org/wiki/Chris_Lattner

swift…マルチパラダイム(オブジェクト指向、関数型、命令型、ブロック、ジェネリック)
ttp://ja.wikipedia.org/wiki/Swift_%28%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%29
wiki覗いてきたけど、「う〜ん、もういいわ」って感じ

このスレもすっかりAppleの植民地になってしまった

Apple信者は「我等こそ正義」とばかりにそこら中で無関係な話題を降り撒くオウムみたいな連中だからな

え、LLVMのソース追っかけたことあるけど、C++と思えない感じですたが、そんなにすごい人なの

別にすごくないんじゃ

もう一人の方はググっても出てこないな。

>>734
LinuxカーネルはGPLにしてなかったら、これだけ普及も発展もしてないよ。
修正BSDだったりしたら、クローズドな、要はソースコードに簡単にアクセス出来ないブランチが沢山出来て、新しいアーキテクチャへの移植や新機能の追加もかなりやりにくくなっていただろうね。
GPLは原理主義的だけど、ソフトウェアの発展の為に敢えて公開性や改変ルールに関して原理主義に徹してきてるライセンスだからね。
ただガンコだとかいう物ではない。

組み込み方面のRTOS上のアプリとかをCやC++で書いてるのから見ると、Swiftって何がいいのかいまいちわからない。
抽象度が高すぎて、しかも下手に柔軟な記述ができちゃうから、グダグダなコードでも動いた積もりになれてしまうというか。
昔、PHPでサーバサイドのアプリ書かされた時と同じようにバグ作り込みやすい言語なんじゃないかと言う気がするんだけど。

>>734
関係ないよ。

彼らの目的を考えれば、コンパイルできるようになればLLVMでフルコンパイルした
ティス鳥を用意するだけだから。GNUのライブラリさえリンクしなければ事足りる。

>>734
clangでもGPLな標準Library使うだけだろ

>>734
Linuxカーネルはコード提供者から著作権を譲渡してもらってない
なので現状のLinuxカーネルの著作権保持者はコード提供者全員ということになっている
GPLの規定でLinuxカーネルのライセンスを変更するにはその人たち全員の同意が必要になり事実上不可能
GPLv2からv3への変更すらも不可能

BSDつかえばいい

そういえばBSDってLinuxバイナリ互換機能もってるのが多いな

>>780
ギークが多いディス鳥から派生してLLVMでコンパイルしたのができそうだな。

>>782
なるほど。以前GPLv2からGPLv3に移行出来ないって話があったがこういうことだったのか。

そもそもLinusがGPLv3を毛嫌いしてる

LinuxがORACLEかどっかに脅されてたっけ

VC用LLVM/Clang 3.4.1あったから試しに入れてC++してみたらとても使えるレベルじゃないんだな。
WinではまだLLVM/Clangはまともに使えるレベルじゃないのか

そこで颯爽と俺がやらねば☆と言えるダンディになりたい

場の理論

稲城サッカースポーツ少年団評判稲城SSS評判
http://i.imgur.com/madZA7O.jpg
東京電機大学中学校評判万引少年S君
http://i.imgur.com/madZA7O.jpg
稲城市立向陽台小学校評判Y子（稲城市百村）
http://i.imgur.com/madZA7O.jpg

>>788
-mwindowsが使えない、gccでも対応してないオプション(何だったかは失念)があるので
icuとか失敗する、icuはconfigureのデフォがclangになってるので(CC=gccにすれば回避)

winだとvc/gcc問わず常用するにはキツいな
主にテストプログラムやエラーの搾り出しに使ってる

cygwinは一応対応していることになってなかったっけ？

clang あるね
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=clang&arch=x86_64

>>775
有名なコンパイラ屋さん
NUMA上のコンパイラとか、
64bitポインタでもメモリ消費しないプログラム変換とか。
ポインタとアーキテクチャの仲人役を
コンパイラにやらせるのが専門。

>>777 Vikram Adve は、イリノイ大学で教授をしてる。 もちろん今でもLLVMにたずさわってる。
インド系の顔をした人。
多分イリノイ大学LLVMの責任者になってるのでは？

初期のLLVM関連の書籍は殆ど二人の共著で、殆どラトナーが第一執筆者になってる。

学生にやらせて。。。な人たちか

>>797 初期の頃はラトナーがほとんど書いて、今でもコミット数はラトナーが一番多いと言ってる。
初期のイリノイ大学で開発してた人達をラトナーはじめAppleに引き抜いたらしい。

学生時代のくせがコードに反映されてるだけか

>>775のこと言ってるの？
ClangのC++やったのは別の人。
C++0xでconceptの仕様と実装書いてたバリバリのC++屋。
LattnerはC++屋じゃない。

C++をマニアックに使いこなさないと
汎用コンパイラ屋として優れてないなんてことはない。
言語は所詮ツールなんでライトに使って
他に注力するのもやり方。

ちなみに最近のLatnerはどっちかというとObjective-C屋さん。
ARC書いたり。

個人的に素人っぽい書き方だなと...ここまでいいたくないけど
動けばいいのでしょうかね、中身関係なく

>>801
そんなに偉そうに言うなら自分からコードコミットすればいいじゃないか。
世の中で大事なのは公の場所で発表する機会と実体の提供をするかしないかなんだもの、何にも発表しないのに酷評だけするのは卑怯者じゃないの？

リアルプログラマとしての実績が世界でも有数の人なんで
プログラマとして素人っぽいとかバカげてる。
その意見の方が素人っぽい。

生成物が良ければ平易な書き方でも何でも良い
テクニカルなコードなんて労力のかける所間違ってる

まあ改善して倍速で動くなら>>801が神だがな頑張れよ(強制

その人以外、コミットできないのでは
あれ、追っかけて弄くるの大変だよ
バラけ過ぎてて

アセンブラとかリンカとかイチから書き直してる人だけど？
速度上げるために。
書ける人は既存のコードがどうとかグダグダ言わない。

プロジェクトが停滞すりゃ直す人とか、
イチから書いてリファインしようぜって人が現れる。
それに対するみんなの対応はいつも
「取り敢えず書いてくれ。良ければ移行する」
こうなるくらい書ける人がリーダーシップ取る世界。

へーへーへー

哀れな801を弄るのはやめてあげて！

低能の自覚はありますが

そんなにわかってるんなら、コミットすりゃいいじゃん
なにをコミットできるの？

マジで言うけどID:ANDVTI9+はしばらく2chやめるべき

とうとつになにをおしゃってるんでしょうか

日本ではClang・VCよりすばらしい自社製C/C++コンパイラ使っているところ多いだろ
そんなところの奴ならClangの中みて何だよこれはってなるだろ

ID:ANDVTI9+ が必死すぎる

林檎にいたご教授をマンセーの方がどう反応するのかなと

>>813
例えば？例えばなに？ねえ？？

COINSのことを言ってるのかなぁ？

>>813
そんなの作れる実力があるなら誰が好き好んでCなんか使うかｗ

>>813
なるほど日本インテルの事ですね？判りますｗ

日本は世界一の超IT技術先進国だからな
ClangはアメリカのようなIT技術後進国用で、超IT技術先進国の日本では使わないだろ？

もはや何を煽りたいのかもよく分からん
俺の頭では読み解けない壮大な皮肉が含まれてるのかな

このスレが活況ないのもなるほどって感じ

単なる馬鹿が一匹紛れ込んでるだけだろ。
多分LLVMが何かすら知ら無いよ。

LLVM Clang Moves A Bit Closer To Compiling The Linux 3.16 Kernel
Published on 08 June 2014 12:07 AM EDT
http://www.phoronix.com/scan.php?page=news_item&px=MTcxNDA

A Quick Look At GCC 4.9 vs. LLVM Clang 3.5　　2014/4/16
http://www.phoronix.com/scan.php?page=article&item=gcc49_compiler_llvm35&num=1
まだ OpenMP対応になっていないようだ。　
マルチスレッドのC-RAYで大きく遅れている。　ｇｃｃ4.9　17.09　Clang　25.84

LLVM Clang、並列処理性能向上　 [2014/05/30]
http://news.mynavi.jp/news/2014/05/30/180/
5月29日(米国時間)にPhoronixに掲載された記事、
「[Phoronix] Benchmarking LLVM's Clang OpenMP Support Against GCC」がLLVM Clang 3.4のOpenMPに関連したベンチマーク結果を伝えた。
次期メジャーアップグレードバージョンとなるLLVM Clang 3.5には並列処理の性能向上につながる（Intel版）OpenMP対応機能が追加されるが、
LLVM Clang 3.4を使ってその性能を評価したといった内容になっている。

Benchmarking LLVM's Clang OpenMP Support Against GCC　　2014/5/29
http://www.phoronix.com/scan.php?page=article&item=llvm_clang_openmp&num=1
Smallptテストでｇｃｃ4.9をキャッチアップ

そもそもガッツリ並列処理やる人はOpenMP使ってないんでは？

OpenMP対応自体は歓迎すべきことだが

どういう書き方しても並列処理ができると勘違いする人が増えたらどうするんだろ

少し古い記事だが

IBM、SystemZでLLVMをサポート
http://news.mynavi.jp/news/2013/05/08/269/
LLVM ClangにIBM SystemZをサポートするコードが追加された(コミット)。
SystemZをサポートするために必要になる基本的な情報やレジスタ名、ドライバ、ABI情報などの基本的な機能が追加されている。
速度的なチューニングや高速化などは今後の対応とされている。

IBMはこれまでLLVM Clangをサポートすべきソフトウェアとはみなしてこなかったが、2012年の間に方針を変更。
LLVM ClangをIBMの提供するPOWERプロセッサベースのサーバでサポートすべきソフトウェアだとして取り組みをはじめていた。
どのような判断で方針を変更したのか、どのような取り組みを行なっているのかが「LLVM on IBM POWER processors A progress report (PDF)」にまとまっている。
http://llvm.org/devmtg/2013-04/weigand-slides.pdf
IBMでは方針を転換した理由として、LLVMの優れたエラーメッセージやサニタイザーなどが開発において有益であること、
特定の顧客からLLVM Clangサポートの要求があること、
JITとしてLLVMが活用されるシーンが増えておりIBMとしても将来的にサポートする必要があること、などを挙げている。

>>826
ガッツリではなくお手軽に並列処理する奴にはOpenMPはなかなか良いものなんだろう

お前らって、業務・プロジェクトにすでにLLVM/Clangを採用している？

macとかiosは殆どclangでしょ

LLVM・JVM の違いを教えて

なんだかんだ言ってたけど、

着実にObj-cはswiftに置き換えが進むようですな

どんな気持ちなんだろうか、

>>832 スレ違い　誰の気持ち？　みんな同じだが？

>>832 素直に嬉しいと殆どの人が思ってるはず
LLVM へ話題を戻すと、LLVMで言語の垣根が幾分取り払われたのかな？

好きな言語で得意な分野を書いてリンクすると言う自由度が増したね

STLとかブーストとかのインストール方法はどうしたらいいですか。
windows用セットアップexeには入ってないです。

LLVM to Java converter の lljvm を source から build してみてるんだけ
ど、新しい LLVM の header には MallocInst class が存在しない。
そもそもこれが何をしてるクラスなのかも分からないけど、代用できるものは
ないのかな？

LLVM から Malloc 命令が消されただけだった。

CrossBridge(FlassCC)のSDKを試してみてる。
付属のgccでビルド途中に llc.exe の実行をトラップして引数を見てみて
たところ、

コマンド名:/xxx/Crossbrigde_1.0.1/sdk/usr/bin/llc.exe
第1引数: jvm=C:\Windows\system32\java
第2引数: -filetype=obj
第3引数: /xxx/Crossbrigde_1.0.1/cygwin/tmp/ccYoCst5.o
第4引数: -o
第5引数: /xxx/Crossbrigde_1.0.1/cygwin/tmp/ccYoCst5.o
第6引数: -jvmopt
第7引数: -Xmx1500M

となっていて、第3引数と第5引数が同じ。つまり、入力ファイルと出力ファイルの
名称が同じになっている。このこと自体も不思議であったので、この段階で永久停止
させて調査してみると、
ccYoCst5.o の中身は先頭が BC というマジックナンバーで、LLVM bitcode の
*.bcファイルと同じになっていた。ところがCrossBridgeに同梱ではない本家cygwin標準
の llvm-nm で覗いてみると

$ llvm-nm ccYoCst5.o
llvm-nm: ccYoCst5.o: Invalid record.

と表示される。

ccYoCst5.o のファイル名を aaa.bc に変えてみても結果は同じだった。

そこで、CrossBridge 付属の llvm-nm で試してみると：

$ /xxx/Crossbridge_1.0.1/sdk/usr/bin/llvm-nm.exe ccYoCst5.o
　　　　　T main
　　　　　U puts

となった。

これは不思議なことで、推定されるのは CrossBridge では、llvm の言語仕様を変えて
しまっているという事。（標準の）LLVM から ActionScript のコードに変えるプロ
グラムがあるなら使おうかと思っていたら、これだと使えない。なぜならもはや正式な
LLVM が使われておらず、使われているのは Adobe 独自の LLVM コードなのだ。
ライセンス上は問題ないんだろうが、してやられた感じがする。
せっかくの共通コード環境だったはずなのに・・・。

>>829
iOS開発じゃ必須だからね。
といってもMicrosoft C/C++ Optimizing Compilerより
遥かに気が利くから嫌々使ってる訳じゃない。

LLVM/Clang 実践活用 ハンドブック、出村成和、2014
読んでもよくわからない
具体性に乏しく、ピンと来ない

ただ、2人のイリノイ大学生の、
見方・切口を変えたアイデアに、皆が飛びついた

結局、プログラミングのネックは、いつも人間にある
JVMのように中間に分割点を置き、作業を前後に分けたことで、
役割分担が進み、考える範囲が狭くなり、理解しやすくなった
ただ、JVMよりもネイティブ側に近づいた

この分野でも、日本車でお得意のすり合わせ型一貫製造が崩れて、
パソコンのように、強固なインターフェースによる、
作業の垂直分散化が進む

すり合わせ型一貫製造って同じ物を繰り返し大量につくるための生産手法やがな

最近の言語乱造ブームは
過去ものの構文とかフロントエンドをちょっぴりオシャレに変えてみました！
程度のちっこい変更に過ぎなくて

Cのライブラリも使えないとね！
という呪縛から逃れられない

ゆえにバックエンドを共通化する意義が大きい

>過去ものの構文とかフロントエンドをちょっぴりオシャレに変えてみました！
>程度のちっこい変更に過ぎなくて

それは言えるな

新言語発表されても
「またか」
っていう感想しか持てなくなった

>>842 バックエンドを考えなければ開発工数がかなり削減される
新言語は単独で全てを揃えることは無理だから既存言語のライブラリを使える事は必須だろ

LLVMを使えばその両方を叶えられるから人気が出て来てるんだろう
LLDBも揃ってるし

LLVM は、開発ツールまで巻き込んで大きな流れになって行くんじゃ無いかな

AppleのSwift をXcodeのPlayground で動かす環境なんてかなり快適な物
こんなのがLLVM陣営の普通の姿になって行くと良いな

>>841
ちなみに、コンパイラ理論では昔からフロントエンドとバックエンドが
分けることが前提になっている。

構文解析後に3つ組みや4つ組みと呼ばれる中間言語を生成する。
この時、レジスタは仮想レジスタと呼ばれるものになっており、
個数の制限が無い。なので1,000個の異なるレジスタを使うこと
も出来る。レジスタが足りなくなった時の処理が大変なので、
いきなりマシンレジスタで考えると処理が複雑になる。

バックエンドでは、仮想レジスタをまだ割り当ててない実レジスタ
に割り付けるか、スタックにメモリ変数として割り付けるか選ぶ。

LVMMは、このバックエンドの部分を外に分離した。

gccも言語用のフロントエンドと分かれてるけど、FSFの判断でコードの分離性が悪い。
その結果alt gccとしての投資がllvmに集まってるんだけれども。

日本人は全工程を一人でモクモクと作る、
職人芸が昔から大好きだし、外人からも驚嘆されている

ABCという工程があって、AをいじくるとBCも変えないといけない
また、CをいじくるとABも変えないといけない(密結合)

これが日本車でお得意のすり合わせ型一貫製造で、
職人芸だから先輩から教えてもらい、
わかるまでに数年かかり、年功序列を生む
前例主義で年上を敬うから、システムの変化を嫌う

作業員が10人いれば、10人ともABCを理解する必要がある
これが、gccが陥ったワナ

いつか、これを崩すものが現れる
ABCのインターフェースを強固にし、各工程3人ずつで、
各人は他の工程を勉強する必要がない
疎結合、垂直(機能)分散、役割分担

関数は単機能で疎結合にしろ、グローバル変数を使うな、
状態変数を使わず関数型言語でやれ、などと同じ

>>848
いや、だいぶ前からあるコンパイラ理論の本にも、前段と後段を分けること
によって、言語をコンパイルして中間言語を生成する層と、最適化や
コード生成を行う層とを分けられる事が書かれている。
前段は、FORTRAN, C, Pascal などで分けるが、後半は全く同じモジュール
を使うことが出来ると。

>>848
判り易い

>>848
gccのこと何も知らないだろ

>>848 gcc の事を象を踊らせても面白くないと言ってる人がいたね。

>>849 その昔、日本の電子計算機会社総出でIBM のSystem360 に負けないコンピュータを作ると言う、通産省主導の超高性能電子計算機 プロジェクトと言うのがあった。

OSを作るために日本総掛で日本ソフトウエアと言う会社を作り、開発してた。
そこでは、PL/I を使って中間言語に落とし、そこから実マシン用の機械語に落とすと言う仕組みを作ってた。

外から見たらIBM360互換マシンとなる。 OSも言語も。

この会社が解散した後各コンピュータメーカーはハードまでIBMを模倣しようとし、アメリカに日立、富士通などがスパイ容疑で捕まった。

GCC（GNUコンパイラコレクション。小文字でgccとした場合はC言語のコンパイラドライバ）は、
フロントエンドとバックエンドはきちんと分離されているが、LLVMが解決しようとした
問題は、フロントエンドとバックエンドの間の中間表現を、外部にエクスポートして、
フロントエンドだけxorバックエンドだけを、GCCとは別のシステムにする、ということができない、
という問題だな。

この、エクスポートできるようにはしない、という決定は政治的なもので、
rmsが、そうするとプロプラエタリなシステムによるフリーライドが容易になるから
ダメ、とした、とされている。

>>852 なんか微妙に話がおかしいんだが...

>>852
そこでPL/I使ったら負けや

>>855 Cがまだ出る前だぞ

オールジャパンと言うが、主幹が日立ということは、HITAC 5020 TSSの記述に使われたPL/IWあたりからの
派生じゃねーのかな？

あと、IBMのプラグコンパチブルマシンを作ったのは日本に限らないし、いわゆる「IBMスパイ事件」は
政治的に演出された「事件」だから。

>>857 >主幹が日立ということは、

全然違うよ。 それはハードウエアの方。
ソフトウエアの方は、日本ソフトウエアの中では実質富士通が勢力を持ってた
日本ソフトウエアが解散した時も、多くの人材をかっさらったのは富士通
その時の人材で作った会社が富士通ソーシャルサイエンスラボラトリ(SSL)

富士通、日立、東芝、日電、三菱、沖
他に勉強のために岩通などの通信会社が研修生を送り込んでた。

http://ja.m.wikipedia.org/wiki/超高性能電子計算機プロジェクト

政治的な理由はこれだね。
そのためアンチプラグインポリシーというのがあるらしい。
http://cpplover.blogspot.jp/2014/01/clang-vs.html

>>857
スーパー301ですね

FLTKを、cygwin-gcc, cygwin-mingw32, msys-mingw32, VC++, clang++
でビルドして試してみた。
このうち、ファイルサイズが最も小さく出来たのはVC++。速度優先に最適化
した場合でさえ、他よりだいぶ小さく出来た。サイズ優先最適化すると
もっと小さくなる。
clang++は、llvmを使っていると思って期待したが、結果は、
多くのexampleにおいて、mingw32のgccより数%大きい。

また、コンパイル速度（コンパイル作業に必要な時間）もVC++が圧倒的に
速い結果となった。gccの4〜5倍程度速い。clang++は、gccと同程度の
コンパイル速度だったと思う。

ただし、clang++に関しては、llvmの最適化ツールを使えばもっとサイズ
ダウンできる可能性はあるが、まだ試してない。

>>861
念のため聞くけど、VCだけCRTがDLLとかは無いよな？

自分の経験だとVCのコンパイルの方が速いというのは無いんだけど、
メモリ容量が効くんだろうか?
FLTKがうまく書けてるから? (プリコンパイルドヘッダーとか?)

>>862
objdumpで確認してみたけど大丈夫だった。
今回、バイナリのサイズ比較に用いたのは、FLTKのexamplesの中にある
menubar-add.cppをコンパイルしてexeにしたもので、FLTKは全て静的リンクした。

1. VC++ : 自分でworkspaceとprojectを作成。サイズ優先最適化 --> 196,608 バイト
　 # msvcrt.dll などは全くリンクしていない。

2. cygwinのmingw32-g++ : mingw32-g++ -Os --> exe --> 288,768 バイト
　 # msvcrt.dll を動的リンクしている。
　 # cygwin1.dll などはリンクしていない。

3. msys+clang : clang++ -Os --> o --> clang++ --> exe --> 296,960 バイト
　 # msvcrt.dll, libgcc_s_dw2-1.dll, libstdc++-6.dll を動的リンクしている。

4. msys+clang : clang++ -Os -emit-llvm --> bc --> cygwinのllvm の opt -Os
　　　　　　　　--> bc --> clang++ でリンク --> strip --> 308,750 バイト

5. msysのmingw32 : g++ -Os --> 284,672 バイト
　 # msvcrt.dll, libgcc_s_dw2-1.dll, libstdc++-6.dll を動的リンクしている。

上記で、system dll の kernel32.dll や gdi32.dll などはどの場合もリンクしている
ので省略した。

clangは、msysのmingw32と同系統のexeを出力していることが分かる。
というのは、libgcc_s_dw2-1.dll, libstdc++-6.dll がmsysのmingw32独特のもの
だから。一方、cygwinのmingw32 は、これらとは別系統で、この2つのdllはリンクしてない。
cygwin1.dllもリンクしてないので、Win32 nativeアプリと言える。4は強くサイズ最適化
するつもりで試してみたがむしろ最適化前より大きくなった。今のところ原因不明。

>>863
今回、プロジェクトは自分で作成した。
pre compiled header は使わないように設定してビルドした。
その場合でさえVC++はコンパイル速度が速い。

今回使ったVC++は古いもので1Coreでしかビルドできないので
CPUパワーは、50%までにしかなってなかった。

ところが、gccの場合は、make -j2でコンパイルした時でさえ、1core
で頑張っているVC++ に負ける。体感速度で少なくとも2倍。なので、-j2
の効果と合わせると4倍以上遅いことになる。

とはいえネイティブのバイナリサイズ気にする時代でもないからなぁ

キャッシュが貧弱だったころは
コードサイズを小さくすることが万能高速化テクニックだったが

>>864 の 2. をさらに小さくしようとして、

-ffunction-sections -fdata-sections
と
-Wl,--gc-sections

を使ってみたが、むしろ大きくなった。

上記オプションを付ける前：288,768
上記オプションを付けた後：300,032

>>866
サイズが大きいと、
馬鹿なんじゃないか。技術力が無いんじゃないか。
馬鹿でも時間かければ出来てしまう時代になったんじゃないか。
いろんなライブラリを集めて来て作られているだけなんじゃないか。

などと邪推されますぜ。

的外れな邪推を気にしてもしょうがない。

サイズが小さいと、
馬鹿なんじゃないか。技術の無駄遣いなんじゃないか。
アセンブラしかない時代に取り残されたんじゃないか。
外部のライブラリを呼び出しているだけなんじゃないか。

などと邪推されますぜ。

サイズが大きいと、たくさんもらえて得したと思うのが一般人

インストールとかバックアップにかかる時間が短くなるなら評価されるだろう

>>871 重たい、大きいで価値を判断する人種も多くいるからな

1GBの辞書の方が500MBの辞書より優れてるだろうと思うのは仕方ない

QtのDLL：
Qt5WebKit.dll : 29.5 MB (Release 版？)
Qt5Widgetsd.dll : 136 MB (Debug 版？)

wxWidgets は、最小GUIアプリ(*.exe)の静的リンク版が1.59MB程度。
MFCアプリが最小のGUI(MDI)アプリで330KB程度。
FLTKが、最小のGUIアプリ190KB程度。

これを見てどういう感想をもつかなんだけど。

>>248 何考えてるんだ？

書き忘れたが、最後の2つも静的リンク版。

wxWidgetsの静的リンク用の*.aファイルは、GUI用のもの(Core)が9MB程度。
*.aファイルは、*.oファイルを集めたものなので、静的リンクする場合は、
そのうちの一部だけがリンクされる。また、*.aファイルにはシンボル情報
などが入っており静的リンクする場合はそれらは除去されるのでもっと
小さくはなる。

あと、Release版であるところの QtWidgets.dll は、5.61MBだった。

>>871-872
デカイ方が機能も多くて手間もかかっているような気がすることは確かに
あるな・・・。

色々複雑だなあ。。。

ターゲットCPUが少ないコンパイラが、
局所最適化が優れているのは当たり前。

LLVMの目的からして、それを主張されてもなあ。
なんのためにあんなアセンブラとはいえない変な中間言語を使っているのか。
それは最適化のためだからと我慢してるわけなのに。
単に仮想変数を使うだけならあんな型情報必要ない。

>>878
LLVMの目的を勘違いしているな

バックエンドを抽象化することによって、
最小限のフロントエンド間発コストで
「程々の性能」の言語処理系を開発できることが
LLVMの最大の利点だよ

特定のフロントエンドかつ特定のアーキテクチャを
ターゲットにしてベンダ(MS)が巨額のコストを投入し開発した
専用コンパイラ(VC++)が、
汎用的なフロントエンドかつ汎用のアーキテクチャに対応した
無償奉仕による汎用コンパイラ(gcc)に負けていたら、
あまりに切なすぎるわ

>>872
ただ、今回の場合を見ても分かるように、同じ機能を持ったアプリでも
サイズがかなり変わってくる。

wxWidgets なんかだと、aui などは別として、Win, Linux, Mac の機能の
共通部分（ A ∩ B ∩ C ) しか使えないことが多く、機能縮小になりがち
なのに、exe のサイズだけは MFC を使った場合の 40 倍に肥大化する。

ただし、一部の機能は少なくともひと古いバージョンのMFCよりは向上して
はいる。それでも、リスト・コントロールのマウスによる列の入れ替えなど
は、OSを超えての共通化が難しいのか、出来ないらしい。Win32やMFCでは
可能であるにもかかわらず。

>LLVMの目的

感染ライセンスの隠t(ry

>>880
javascriptωに負けてるな

MSのように資源を1つに集中させるか、
LLVMのように多様性を追求するかの違い

集中政策を採ったものは、ユーザが多いから、
埋没・変化コストが高く、変化できない、
または、緩やかに変化していくことが難しいから、
いつかは破綻する

会社のリストラや日本の高齢化と同じで、
何かを変えようとすると、
損する人・嫌がる人(アンチ)が出てくる

変えるためには、賛成派は2/3以上、
アンチは1/3以下が必要

intel cpuならiccあるし、armにもarm社製の商用cコンパイラあるんだっけ？
今の時代、cコンパイラ自体はブラウザ競争みたいに独自拡張の競争にはならない気がする。

>>884
ARMは基本、商用コンパイラだよ。
gccもあるけど普通は使わないよ。

スマン。
wxWidgetsを静的リンクした時のサイズは、MFCのそれの40倍でな
く、4〜5倍だった。

>>877 >>879
それでも、clangは、x86系CPUを使ったMac OS Xから出てきた物な
わけで、clang(LLVM)がx86系でいいコードを吐かないのは理由には
ならないんじゃないの。非LLVMのgccにさえ負けてるし。

gccやVCは枯れているのに対し、LLVMはまだまだ発展途上
今結論を出す奴はくたびれ儲けになるだけ

x86系のSIMDだとSSEをAVXでコンパイルし直しただけでも最適化の効きが違うよ
内部表現を2オペランド化する過程でかなり質が低下してるようだ
組み込み関数で半分答え書いてるようなものなのに人間に負けてるんだもん
MIPS用gccはもっと洗練されたコードが出力されてた気がするし

>>883
windows8みたいにユーザーの同意なく変えることもあるが

>>885
ARMの現在最多プラットフォームと思われるAndroidはgccじゃん。

>>887
clangはフロントエンドだろ。バックエンドの話してるのに、
> x86系CPUを使ったMac OS Xから出てきた
とか意味不明の理屈で無理やり絡めるなよ。

gccはRTLに対して最適化されたコード列を
クロック計算して試行錯誤で見つけるソフトウェアがあったはずだが、
いつの間にかなくなっていたな。
最近のCPUはクロック数計算難しいからかな?

>>891
ARMは自動車や家電の制御、Nintendo DSシリーズ、ワンボードマイコン等Androidと比較にならない大きい市場のプラットホームで使われている。

>>894
その中で最大「プラットフォーム」は任天堂DS?
これがハードウェアプラットフォームで世界最多なんでしょ。
それでもAndroidより一桁少ないんじゃないの?

何の議論をしたいのかわからない。

>>892
え、でも LLVM 自体が Apple が提唱したものじゃなかったっけ。

ぜんぜん違う

>>895
ARMは2011年に79億個のチップロイヤリティを受け取っていて、Androidは2012年に
3億5700万台出荷されたらしいので、逆なんじゃない？

http://eetimes.jp/ee/articles/1205/16/news007.html
http://itpro.nikkeibp.co.jp/article/NEWS/20120912/422182/

ちなみにARMって安いのは80円とかでお店で売ってるよ。

AppleとLLVMの最初の関わりは、
CPU非依存のOpenGLのGLSL処理系を作るために、既存のLLVMを使ったこと。

おどろくべきことはGPU非依存よりCPU非依存の方が先に目標になったこと。
PowerPCからx86への移行コストが馬鹿にならなかったので。
主に自社開発のGLSL用独自JITの開発が。
これはOpenGLがGLSLという内部言語を強要する規格だから起きた。

>>899
CPUの出荷数の話?
CPUはプラットフォームじゃないよね。
プラットフォームの意味がわかってないから頓珍漢なレスするんだろうけど。

>>902

> ARMは基本、商用コンパイラだよ。
> gccもあるけど普通は使わないよ。

これに対して

> ARMの現在最多プラットフォームと思われるAndroidはgccじゃん。

と言う話だから、出荷量から考えてgccはあまり使われてないってことで良いんじゃないかな。
ARMの大部分は内蔵メモリで動かすからgccはちょっときついんだろね。

gccはOSS方面でも次第にClang+LLVMに置き換えられていくんじゃないかな。
アップルが力を入れてるからOSSコミュニティでは太刀打ちできないと思うよ。
ユーザー側としては、いつ乗り換えるかが関心事になると思う。

>>881 の t が気になって眠れない

>>905
ごめん書いたら組織が

>>905
普通にエスパーすれば「隠匿」じゃね？

LLVM/Clang 3.5出たからやほーーってVS用を入れたけど
例外はサポートしていないんだな。いつになったらサポートするん？

2chは、不利な事実を書いても体制を擁護する意見ばかりが目立つね。

実は公務員率は高い

「体制」と言ったのは、AppleやQt, gcc, Linux のことなんだけど。

x86バイナリーをどうやったらLLVMに翻訳できますか？

アセンブラに戻してLLVM中間言語に変換

Assemblyではダメでしょうか

だめよ〜、だめだめ

LLVM 言語マニュアル (Language Reference Manual)
ttp://www.h3.dion.ne.jp/~mu-ra/llvm/LangRefJ.html

日本語訳です。ただし、翻訳は適当と書いてある

x86バイナリーを、LLVMに変換できるの？
x86バイナリー → アセンブラ → LLVM？

LLVMにすれば、optコマンドで、dotファイルに変換して、
GraphViz を使って、構造をグラフ図にして見れる

除去された識別子や最適化による変形はもちろん元に戻りません

何時に成ったらWindowsで使えるんだよ

一時は cygwin のパッケージにあって使えてたんだけれども最近急になくなったようだ‥今はどうなのか？

お試しで使うだけなら llvm の公式バイナリDLするだけじゃろ

>>920
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=llvm&arch=x86_64
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=clang&arch=x86_64
あるけど

.Netの一部がオープンソース化したという事で .Netを主軸とした窓帝国、LLVM=>asm.js を主軸とした林檎教団の形が見えてきました。

ところが、いち早くHTML5を掲げた自称おプ祖守護神は足場が見えてませんね。パイソン技術者には下回りは作れないという事なのか。
クロムとアンドロイドをこのまま続けて時代遅れとなるだろうOS市場で戦うことになるのか、はたまた失敗続きのWEBサービスを何かひねり出すのか。
まさか検索で喰い詰めていくのか・・・。ロボットやドローンに興味があるようなので職種を転換するのか。

先行する林檎教団を劣勢な窓帝国が追いかける二強時代に突入するのか

小説家に転職されたほうが

※付けて、注釈をたくさん入れたSFだな。

LinuxのディストリのLLVM/Clang対応ってどの辺まで進んでんだろ？

BSD系の方使われる方が
対応表明早かったし

>>926
ClangではGCCの拡張機能マンセー物は駄目だろうが
いまやそれ以外のアプリはGCCでなくLLVM/Clangでビルドが標準だろ

確か、BSDはClangになったんだよね？

ライセンスが素敵だからとかで

Linuxカーネルは3.16あたりからLLVMLinuxの成果を取り込んで
ビルド出来るようになるそうだがディストリのLLVM/Clang対応はどうなってんだか。

Linuxカーネルは gcc に独自仕様を入れて使ってるから clang に出来ねぇって言われてたやつか

選択肢は増やしてあげるから後は好きにやれば？　って話じゃないの

WindowsでClangを使う時は今の所32bitバージョンしかないのか
ひでえなおい

全く高いカネぼったくっておいて何たるザマだ

LLVMはマカー用だから、Winで動かなくても構わないんだよ。Linuxですらどうでもいいのだから

Clang / LLVMがまともに使いたければ素直にFreeBSD使えってこと

現時点でも、おそらく将来もgccに最適化でガチ勝負して勝てるようにならない気がするんだが
LinuxでLLVMを使う利点なんて興味意外にないだろ

mesaが使ってますね
C系の置換えというより別な使い方ができるようなので

clangの話をするときにLLVMって呼ばれると紛らわしすぎる

>>937
gccはCOBOLやPerlやJavaみたいに何十年たっても不可欠な存在だよ

>>937
何事にも冗長性は大切だよ
何時でも第二、第三の存在がないと結局は破滅が待ってるってことは世の常
ましてやあそこまで肥大化したプロジェクトを一日二日で置き換えるものができるわけないし

gccに比べるとclang/llvmの開発速度は驚異的だと思う

その根拠は？
ただの個人的感想？

新しいC++のサポートとかもgccは遅いもんね

は？

は？（威圧）

そんなとこ、早いって
なんかまともなもの作って動かしたことある？

LLVMくらいのものを作らないと書込できないとしたらこのスレはすぐDAT墜ちだなw

>>942
サポートCPU、言語が少ないからでしょ。

対応CPUに関しては、微妙

ちょっと遊んでみようと思ってWindows版バイナリを落としてみたけど、llvm-asやllcなどは
同梱されてないんですね。
これらを使いたければ自分でビルドするかlinux版なりを使えってことですかね？

ちょっと試すだけならEmscriptenのバイナリパッケージにllvm-asやllc入ってる
jsバックエンド追加以外の変更がどうなってるのか知らないけど

ありがとう。
試したかったのは.llからCソースへの変換だけど、emscripten自体も面白そうですね。

LinuxのX86・ARMはもうじきLLVMでコンパイルできるんだっけか？

それってどういう環境で実行できるの

クロスビルド（あるいはカナディアン）じゃなくてセルフでしょ？

gccに依存なasm部分はどうするんだろ
ソースでLLVM用にするのか、（擬似関数でゴニョゴニョ）

脱gcc依存コード的な話をどっかで読んだような？

http://i.imgur.com/nIdG8KN.jpg

>>959
LLVM愛が伝わってくるぜ ヒシヒシと

パッパラーパーのメーカー向けに作ってたから中身も・・・

Microsoft、オープンソースの.NET実行エンジン「CoreCLR」を公開 | スラッシュドット・ジャパン オープンソース
http://opensource.slashdot.jp/story/15/02/08/0721252/

ん？そのニュースLLVM関係あるんすか？
対抗馬の紹介みたいな意図かしらん
いやまあ素で今後の発展に期待してるけど。個人的にはC#好大好物です

マルチポストに反応してましたすみません
穴があったら入れたい

うれし〜
ぼく〜

このスレのはじめの頃のレベルは高いな

3.6で加わったGoのbindingどこにあるの？