5

に影響は何ですか

  • 移植性（呼び出し規約：CまたはOSライブラリ関数のみを呼び出す場合、LLVMレベルで本当に重要ですか）
  • リンク時間
  • 最適化

すべての難しい部分（最適化、オブジェクトコード生成）がすでに存在するため、LLVMを使用しておもちゃの言語をコンパイルしたいのですが、それが価値がある場合は維持したい概念に苦労しています：ライブラリファイルは再配布可能、静的および共有ライブラリとして使用可能（リンクの場合、共有の場合、最終的なアプリがリンクされたときに実際のsoまたはdllが生成されます）、ポータブル。これにより、コンパイル時間の一部が削減されると思います（ネイティブコードの生成とおそらく最適化は、最終的なバイナリリンク時に1回だけ実行されるため）。リンカが呼び出し規約（可能な場合）と、要求された場合は共有ライブラリへの変換を処理することを想定しています。広範囲にわたる追加では、おそらくLLVMを活用してリンクし、LLVM JITを使用して、生成されたバイトコードを直接実行し、コードを記述する際のリンク時間を完全に削除します。

この音は聞こえますか

  1. 実行可能ですか？
  2. 価値がある？C / C ++のリンク時間が比較的長いことは知っていますが、これは頻繁に再構築するときに問題になります。フリーリンク時間の最適化についてはどうでしょうか（cfr/GLと-flto、本質的にLLVMバイトコードがリンクされ、ネイティブバイナリに変換されるため）。

これは漠然とした質問かもしれませんが、何か明確にする必要がある場合は、質問してください。

4

1 に答える 1

8

私は過去にこれに似たようなことをしました。LLVMビットコードは完全にマシンに依存しないという点で「ポータブル」ではないことを理解しておく必要があります。ビットコードファイルには、対象となるプロセッサに固有のポインタのサイズなどの知識があります。

そうは言っても、これまで私はプログラムとそのサポートライブラリをコンパイルしてビットコード化し、プログラム全体のアセンブリファイルを生成する前にビットコードファイルをリンクしていました。確かに、内部の呼び出しでは呼び出し規約は重要ではありませんが、外部（または外部）からの呼び出しでは、ABIに従う必要があります。

プロセッサに依存するビットコードを回避できるようにおもちゃの言語を設計できる場合もありますが、非常に注意する必要があります。

特に高い最適化レベルでは、ビットコードファイルをリンクするのにかなりの時間がかかることに気づきました。それは今ではスピードアップしているかもしれませんが、私は2、3年前からLLVMでそれを行いました。

最後のポイント：ターゲットプロセッサによっては、プロセッサに浮動小数点や64ビット整数のものが好きではないものを処理するためにlibgcc.aまたはcompiler-rtと同等のものがおそらく必要になります。それらの操作を実行します。

于 2012-02-18T17:24:52.190 に答える