コンパイラの時間の複雑さ

コンパイラの時間の複雑さに興味があります。考慮すべきコンパイラ、コンパイラオプション、変数が多数あるため、これは明らかに非常に複雑な質問です。具体的には、LLVMに興味がありますが、人々が持っていた考えや研究を始める場所に興味があります。かなりグーグルはほとんど何も明らかにしないようです。

私の推測では、指数関数的ですが、実際の時間にはほとんど影響しない最適化手順がいくつかあると思います。たとえば、数値に基づく指数関数は関数の引数です。

私の頭の上から、私はASTツリーの生成は線形であると言うでしょう。IR生成では、増加し続けるテーブルの値を検索しながらツリーをステップスルーする必要があるため、またはO （n log n ）となります。コードの生成とリンクは、同様のタイプの操作になります。したがって、現実的に成長しない変数の指数関数を削除した場合、私の推測はO （n 2）になります。$O(n^2)$$O(n\log n)$$O(n^2)$

私は完全に間違っている可能性があります。誰もそれについて何か考えがありますか？

質問に答えるのに最適な本は、おそらくCooper and Torczon、 "Engineering a Compiler、" 2003です。大学図書館にアクセスできる場合は、コピーを借りることができます。

$O(n^2)$$n$

$O(n)$$O(n)$

$O(n)$$O(1)$$O(s)$$s$

次に、解析ツリーは通常、制御フローグラフに「フラット化」されます。制御フローグラフのノードは3アドレス命令（RISCアセンブリ言語に類似）である可能性があり、制御フローグラフのサイズは通常、解析ツリーのサイズに比例します。

$O(d)$$d$$O(n)$$n$

より高度な最適化を行うには、より高度な分析を行うことをお勧めします。この時点で、トレードオフに陥り始めます。解析アルゴリズムによりもはるかに少ない時間がかかることを望む$O(n^2)$プログラム全体のフローグラフのサイズの時間ですが、これは、証明するのに費用がかかる情報（およびプログラムを改善する変換）なしで行う必要があることを意味します。この典型的な例はエイリアス分析です。ここでは、メモリ書き込みのいくつかのペアについて、2つの書き込みが同じメモリ位置を決してターゲットにできないことを証明したいと考えています。（エイリアス分析を実行して、1つの命令を他の命令の上に移動できるかどうかを確認することもできます。）しかし、エイリアスに関する正確な情報を取得するには、プログラム内のすべての制御パスを分析する必要があります。プログラム内（したがって、制御フローグラフ内のノード数の指数関数的）

次に、レジスタの割り当てに入ります。レジスターの割り当ては、グラフの色付けの問題として表現することができ、最小数の色でグラフを色付けすることはNPハードであることが知られています。そのため、ほとんどのコンパイラーは、レジスターのスピル数を合理的な時間内にできる限り減らすことを目的に、レジスターのスピルと組み合わせたある種の貪欲なヒューリスティックを使用します。

最後に、コード生成に入ります。コード生成は通常、一度に最大の基本ブロックで実行されます。この場合、基本ブロックは、単一のエントリと単一の出口を持つ線形接続された制御フローグラフノードのセットです。これは、カバーしようとしているグラフが基本ブロック内の3アドレス命令のセットの依存グラフであり、使用可能なマシンを表すグラフのセットでカバーしようとしている問題をカバーするグラフとして再定式化できます。指示。この問題は、最大の基本ブロックのサイズが指数関数的であるため（原則として、プログラム全体のサイズと同じ順序になる可能性があります）、これは通常、可能性のあるカバーのごく一部のみが発見的手法で行われます調べた。

実際、一部の言語（C ++、Lisp、Dなど）はコンパイル時にチューリング完全であるため、一般にコンパイルは決定できません。C ++の場合、これはテンプレートの再帰的なインスタンス化が原因です。LispとDの場合、コンパイル時にほとんどすべてのコードを実行できるため、必要に応じてコンパイラを無限ループにスローできます。

C＃コンパイラの実際の経験から、特定のプログラムでは、出力バイナリのサイズは入力ソースのサイズに対して指数関数的に増加する（これは実際にはC＃仕様で必要であり、削減できない）と言えます。少なくとも指数関数でなければなりません。

C＃の一般的なオーバーロード解決タスクはNP困難であることが知られています（実際の実装の複雑さは少なくとも指数関数的です）。

C＃ソースでのXMLドキュメントコメントの処理には、コンパイル時に任意のXPath 1.0式を評価することも必要です。

オープンソースプロジェクトのセットなど、現実的なコードベースで測定します。結果を（codeSize、finishTime）としてプロットすると、それらのグラフをプロットできます。データf（x）= yがO（n）である場合、データが大きくなり始めた後、g = f（x）/ xをプロットすると直線が得られます。

f（x）/ x、f（x）/ lg（x）、f（x）/（x * lg（x））、f（x）/（x * x）などをプロットします。ゼロまでオフ、無制限に増加、または平坦化。このアイデアは、空のデータベースから開始する挿入時間を測定するような場合に役立ちます（つまり、長期にわたって「パフォーマンスリーク」を探すため）。