私は自己改善型のコンパイラーを知りませんが、それでも私はコンパイラーの専門家ではありません。
自己改善コンパイラはありますか？
私はそれ自体を改善するコンパイラについて話していることに注意してください-それがコンパイルするコードを改善するコンパイラではありません。
どんなポインタでもありがたいです！
補足：なぜ私が尋ねているのか疑問に思っている場合は、この投稿を見てください。私がほとんどの議論に同意したとしても、私は次のことについてあまり確信がありません：
現在、人間の入力なしでコードを改善できるプログラムがあります—それらはコンパイラと呼ばれています。
...したがって私の質問。
コンパイラーが人間の干渉なしにコードを改善できることは事実ですが、「コンパイラーは自己改善している」という主張はかなり疑わしいものです。コンパイラーが行うこれらの「改善」は、人間（サイボーグは誰か？）によって書かれた一連のルールに基づいているだけです。だからあなたの質問への答えは：いいえ。
ちなみに、自己改善コンパイラのようなものがあれば、私たちは知っているでしょう...最初に言語を改善し、次に独自のコードを改善し、最後にコードを変更してウイルスになり、すべての開発者を作りますそれを使用してください...そして最後に、私たちはそれらの古典的なコンピュータ対人間の最後の希望のようなものの1つを持っているでしょう...だから...いいえ。
MilepostGCCはMachineLearningコンパイラであり、時間とともに「より良く」なるために自分自身を変更できるという意味で、時間とともに自分自身を改善します。より単純な反復コンパイルアプローチは、ほとんどすべてのコンパイラを改善することができます。
25年間のプログラミングで、そのようなことは聞いたことがありません（ソフトウェアの更新を自動ダウンロードするコンパイラについて話している場合を除きます）。
私の知る限り、まだ実際には実装されていませんが、そうです、理論はそこにあります：
自己改善コンパイラは、定義上、自己修正コードを持っている必要があります。周りを見渡せば、これを行っている人々の例を見つけることができます（自己修正コード）。ただし、特にコンパイラのように大規模で複雑なプロジェクトでは、これを確認することは非常にまれです。そして、正しい機能を保証することが途方もなく難しい（つまり、ほぼ不可能である）という非常に正当な理由から、それは珍しいことです。賢いと思う多くのコーダー（特にAssemblyコーダー）は、ある時点でこれをいじくり回します。実際に賢い人は、ほとんどこの段階から抜け出します。;）
状況によっては、Cコンパイラは人間の入力なしで数回実行され、毎回「より優れた」コンパイラを取得します。幸いなことに（または残念なことに、別の観点から）、このプロセスは数ステップ後にプラトーになります。さらに繰り返すと、最後とまったく同じコンパイラ実行可能ファイルが生成されます。
すべてのGCCソースコードがありますが、このマシンで使用できるCコンパイラはGCCだけではありません。残念ながら、GCCの一部は、GCCでのみ構築できる「拡張機能」を使用しています。幸い、このマシンには、機能的な「make」実行可能ファイルと、ランダムなプロプライエタリCコンパイラがいくつかあります。人間はGCCソースのあるディレクトリに移動し、手動で「make」と入力します。
makeユーティリティはMAKEFILEを見つけます。これは、（独自の）Cコンパイラを実行してGCCをコンパイルし、「-D」オプションを使用して、「extensions」を使用するGCCのすべての部分が#ifdefされるようにします。（これらのコードは、一部のプログラムをコンパイルするために必要な場合がありますが、GCCの次の段階では必要ありません。）これにより、非常に限定されたカットダウンバイナリ実行可能ファイルが生成され、GCCをコンパイルするのに十分な機能がほとんどありません（GCCコードを作成する人は、このカットダウンバイナリがサポートしていない機能の使用を慎重に避けます）。
makeユーティリティは、適切なオプションを使用してその削減されたバイナリ実行可能ファイルを実行し、GCCのすべての部分がコンパイルされるようにして、完全に機能する（ただし比較的遅い）バイナリ実行可能ファイルを作成します。
makeユーティリティは、すべての最適化オプションをオンにして、GCCソースコードで完全に機能するバイナリ実行可能ファイルを実行します。これにより、今後人々が使用する実際のGCC実行可能ファイルが作成され、適切な場所にインストールされます。
makeユーティリティは、すべてが正常に機能していることを確認するためにテストします。すべての最適化オプションをオンにして、GCCソースコードの標準の場所からGCC実行可能ファイルを実行します。次に、結果のバイナリ実行可能ファイルを標準の場所にあるGCC実行可能ファイルと比較し、それらが同一であることを確認します（無関係なタイムスタンプを除いて）。
人間が「make」と入力すると、プロセス全体が自動的に実行され、各ステージで改善されたコンパイラが生成されます（プラトーになり、同一のコンパイラが生成されるまで）。 http://gcc.gnu.org/wiki/Top-Level_Bootstrapとhttp://gcc.gnu.org/install/build.htmlおよびCompileGCCwith Code Sourceryには、さらにいくつかの詳細があります。
このプロセスにはさらに多くのステージがある他のコンパイラーを見てきましたが、それらはすべて、各ステージまたは2つのステージの後に人間の入力を必要とします。例：Edmund GrimleyEvans2001による「単純なコンパイラのブートストラップ」 http://homepage.ntlworld.com/edmund.grimley-evans/bcompiler.html そしてGCCに取り組んだプログラマーによって行われたすべての歴史的な作業があります、以前のバージョンのGCCを使用して、おそらく改善されたバージョンのGCCで投機的なアイデアをコンパイルおよびテストします。これが人間の入力なしであるとは言えませんが、コンパイラは人間のキーストロークごとにますます多くの「作業」を行う傾向があるようです。
さて、JIT（ジャストインタイム）技術があります。いくつかのJIT最適化を備えたコンパイラーは、コンパイルしているプログラムでより効率的になるように再調整する可能性があると主張する人もいるかもしれません。
適格かどうかはわかりませんが、Java HotSpotコンパイラは、統計を使用して実行時にコードを改善します。
しかし、コンパイル時に？そのコンパイラは、何が不足していて何が不足しているかをどのように知るのでしょうか？良さの尺度は何ですか？
「より良い」解決策を考え出すためにアルゴリズムを互いに比較するために遺伝子技術を使用している人々の例はたくさんあります。しかし、これらは通常、メトリックを持つよく理解されている問題です。
では、コンパイル時にどのようなメトリックを適用できるでしょうか。コンパイルされたコードの最小サイズ、サイクロメトリックの複雑さ、または他の何か？これらのうち、実行時に意味があるのはどれですか？