LLVMを使用したプログラミング言語の作成。 パート10：結論とその他のLLVMの利点

目次：

パート1：はじめにと字句解析

パート2：パーサーとASTの実装

パート3：LLVM IRコード生成

パート4：JITおよびオプティマイザーサポートの追加

パート5：言語拡張：制御フロー

パート6：言語拡張：ユーザー定義演算子

パート7：言語拡張：可変変数

パート8：オブジェクトコードへのコンパイル

パート9：デバッグ情報の追加

パート10：結論とその他のLLVMの利点

9.1。 おわりに

チュートリアル「LLVMを使用したプログラミング言語の作成」の最後の部分にようこそ。 このチュートリアルを通して、小さな万華鏡の言語を役に立たないおもちゃからかなり面白い（おそらく役に立たないかもしれませんが）おもちゃに成長させました。



私たちがどこまで来たのか、これが必要とするコードがどれだけ少ないのかを見るのは興味深いです。 完全なレキシカルアナライザー、パーサー、AST、コードジェネレーター、対話型実行（JITを使用！）、およびデバッグ情報をスタンドアロンの実行可能ファイルに生成しました-これはすべて、1000行未満のwad（空の行とコメントを除く）です。



私たちの小さな言語は、いくつかの興味深い機能をサポートしています。ユーザー定義の二項演算子と単項演算子をサポートし、JITコンパイルを使用して即座に実行し、SSA形式でコードを生成してフロー制御構造をサポートします。



このガイドのアイデアの一部は、言語の定義、構築、および操作がどれほど簡単かを示すことでした。 コンパイラの構築は、恐ろしいプロセスや神秘的なプロセスである必要はありません！ 基本を理解したので、コードを取得して対処することを強くお勧めします。 たとえば、追加してみてください：



グローバル変数-現代のソフトウェア工学におけるグローバル変数の値は疑わしいものですが、それらは多くの場合、Kaleidoscopeコンパイラ自体などの小さな高速ハックに使用されます。 幸いなことに、プログラムにグローバル変数を追加するのは非常に簡単です。各変数がグローバルシンボルテーブルにあるかどうかを確認するだけです。 そのために。 新しいグローバル変数を作成するには、LLVM GlobalVariableクラスのインスタンスを作成します。

型付き変数-Kaleidoscopeはdouble変数のみをサポートするようになりました。 これにより、言語が非常にエレガントになります。1つの型のみをサポートすることは、変数の型を指定する必要がないためです。 言語が異なれば、この問題を解決する方法も異なります。 最も簡単な方法は、ユーザーに各変数定義のタイプを指定するよう要求し、値*とともにシンボルテーブルに変数のタイプを書き込むことです。

配列、構造、ベクトルなど タイプを入力すると、さまざまな興味深い方向にタイプシステムを拡張し始めることができます。 単純な配列は、さまざまなタイプのアプリケーションに非常に単純で便利なものにすることができます。 LLVM getelementptr命令がどのように機能するかを学習するための演習として追加してください。非常にエレガントで珍しいため、独自のFAQがあります。

標準ランタイム-現在の形式では、言語はユーザーに任意の外部関数にアクセスする機能を提供します。これを「printd」や「putchard」などに使用します。 言語を拡張して、より高いレベルの構成体を追加できます。多くの場合、このような構成体をコマンドのインラインシーケンスの形式で作成するよりも、ランタイム関数に持って行く方が理にかなっています。

メモリ管理-カレイドスコープ言語では、スタックのみにアクセスできます。 また、標準のlibc malloc / freeインターフェイスを呼び出すか、ガベージコレクターを使用して、ヒープにメモリを割り当てると便利です。 ガベージコレクタを使用する場合は、LLVMがオブジェクトの移動アルゴリズムやスタックのスキャン/更新に必要なアルゴリズムを含むAccurate Garbage Collectionを完全にサポートしていることに注意してください。

例外サポート-LLVMは、ゼロコストで、他の言語でコンパイルされたコードと対話する機能を備えた例外の生成をサポートします。 各関数がエラー値を返し、これをチェックすることを暗示するコードを生成することもできます。 setjmp / longjmpを明示的に使用して、例外を実装することもできます。 一般に、多くの異なる方法があります。

OOP、ジェネリック型、データベースへのアクセス、複素数、幾何学的プログラミング、...実際、言語に追加できるクレイジーなものに終わりはありません。

珍しいアプリケーション-LLVMを多くの人が興味を持っている分野で使用することについて話しました：特定の言語用のコンパイラの構築。 ただし、一見コンパイラの使用が考慮されていない他の多くの領域があります。 たとえば、LLVMはOpenGLグラフィックスの高速化、C ++コードのActionScriptへの変換、およびその他多くの興味深いことのために使用されます。 おそらく、LLVMを使用してネイティブの正規表現コードにJITコンパイラを構築する最初の人になるでしょうか？

喜び-クレイジーで珍しいことをしてみてください。 言語を他の人と同じにすることは、何かを狂わせるほど楽しくありません。 これについて話したい場合は、llvm-devメーリングリストに気軽に書き込んでください。言語に興味があり、しばしば助けたい人がたくさんいます。



チュートリアルを完了する前に、LLVM IRを生成するためのヒントを提供したいと思います。 明らかではないかもしれない微妙な点がいくつかありますが、LLVMの機能を利用したい場合には非常に便利です。

10.2。 LLVM IRプロパティ

LLVM IRコードについては2、3の質問があります。それらを今見てみましょう。

10.2.1。 ターゲットプラットフォームの独立

万華鏡は「ポータブル言語」の一例です。万華鏡で書かれたプログラムは、それが起動されるターゲットプラットフォーム上で同じように動作します。 Lisp、Java、Haskell、Javascript、Pythonなど、他の多くの言語にも同じプロパティがあります。 （これらの言語は移植可能ですが、すべてのライブラリが移植可能であるわけではないことに注意してください）。



LLVMの優れた側面の1つは、IRレベルでターゲットプラットフォームからの独立性を維持することです：KaleidoscopeでコンパイルされたプログラムのLLVM IRを取得し、LLVMでサポートされる任意のターゲットプラットフォームで実行できます。ネイティブにサポートします。 Kaleidoscopeコンパイラーは、コードを生成するときにプラットフォームに関する情報を要求しないため、プラットフォームに依存しないコードを生成すると言えます。



LLVMがプラットフォームに依存しないコンパクトなコード表示を提供するという事実は非常に魅力的です。 残念ながら、人々はしばしば言語の移植性について尋ねるとき、CまたはCに似た言語のコンパイルについて考えるだけです。 「残念ながら」と言ったのは、実際にはCコードを移植することは（一般的な場合）不可能であるためです。もちろん、移植の場合でも、Cソースコード自体は一般的な場合移植性がないからです。 32〜64ビットのアプリケーション。



Cの問題（これも一般的なケースです）は、プラットフォーム固有の仮定に大きく依存していることです。 簡単な例として、プリプロセッサは次のテキストを処理する場合、コードプラットフォームを依存させます。

#ifdef __i386__ int X = 1; #else int X = 42; #endif
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この問題をさまざまな複雑な方法で解決することは可能ですが、一般的な方法では解決できません。



ただし、Cのサブセットは移植可能にすることができます。 固定サイズ（たとえば、int = 32ビット、long = 64ビット）のプリミティブ型を作成する場合、既存のバイナリファイルとのABI互換性について心配せずに、他の機能を放棄すれば、移植可能なコードを取得できます。 これはいくつかの特別な場合に意味があります。

10.2.2。 セキュリティ保証

言及された言語の多くは「安全」でもあります。Javaで書かれたプログラムがアドレス空間を台無しにしてプロセスを落とすことは不可能です（JVMにバグがないと仮定）。 セキュリティは、言語設計、ランタイムサポート、および多くの場合OSサポートの組み合わせを必要とする興味深い機能です。



LLVMで安全な言語を実装することは確かに可能ですが、LLVM IRだけではセキュリティを保証しません。 LLVM IRでは、安全でないポインター変換、解放後のメモリー使用、バッファーオーバーフロー、その他のさまざまな問題が発生します。 セキュリティはLLVMよりも高いレベルで実装する必要があり、幸いなことに、いくつかのグループがこの問題を調査しています。 詳細については、llvm-devメーリングリストで質問してください。

10.2.3。 言語固有の最適化

LLVMには、多くの人が気に入らないものが1つあります。1つのシステムで世界のすべての問題を解決するわけではありません（申し訳ありませんが、飢えている子供、他の誰かがあなたの問題を解決する必要があります。 LLVMからの不満の1つは、言語固有の高度な最適化を実行できないことです。LLVMは「情報を失いすぎます」。



残念ながら、「コンパイラー設計の理論」の完全で普遍的なバージョンを書く場所はありません。 代わりに、いくつかの観察を行います。



LLVMは情報を失っています。 たとえば、SSA値がILP32マシンのタイプC「int」または「long」から生成されたかどうかをLLVM IRレベルで区別することはできません（デバッグ情報を除く）。 どちらもタイプ「i32」の値にコンパイルされ、ソースタイプに関する情報は失われます。 より一般的な問題は、LLVM型システムが、同じ名前の同等の型ではなく、同じ構造を持つ型を考慮することです。 これは、同じ構造を持つ高レベル言語の2つの型（たとえば、1つのintフィールドを持つ2つの異なる構造）がある場合、これらの型が1つのLLVM型にコンパイルされ、不可能になることを人々を驚かせます変数がどの初期構造に属しているかを言います。

第二に、LLVMは情報を失っていますが、ターゲットプラットフォームが固定されていません。さまざまな方向に情報を拡張および改善し続けています。 新しい機能を追加します（LLVMは常に例外やデバッグ情報をサポートしていませんでした）、IRを拡張して最適化に重要な情報（引数がゼロまたは符号付きビットで拡張されたかどうか、ポインターのエイリアスに関する情報など）をキャプチャします。 多くの改善はユーザーによって開始されます。人々はLLVMに特定の機能を持たせたいと思っています。

第三に、言語固有の最適化を簡単に追加することが可能であり、これを行う方法はいくつかあります。 簡単な例として、ソースコードについてさまざまなことを「知っている」最適化パスを簡単に追加できます。 Cに似た言語の場合、この最適化パスは標準Cライブラリの関数を「認識」します。main（）で関数「exit（0）」を呼び出すと、呼び出しは安全に「return 0」に変換できることがわかります。標準Cは、出口関数が行うべきことを記述しています。



ライブラリの単純な知識に加えて、LLVM IRに他のさまざまな言語固有の情報を埋め込むことができます。 特定のニーズがある場合は、llvm-devメーリングリストに書き込んでください。 最悪のシナリオでは、LLVMを「ダムコードジェネレーター」とみなし、言語固有のASTでフロントエンドに高レベルの最適化を実装できます。

10.3。 トリックとトリック

LLVMで作業した後、さまざまな便利なトリックやトリックがありますが、それらは一見して明らかではありません。 誰もがそれらを再発見しないように、このセクションではそれらのいくつかに専念します。

10.3.1。 ポータブルoffsetof / sizeofの実装

興味深いのは、コンパイラによって生成されたコードを「プラットフォームに依存しない」状態に保ちたい場合、LLVMタイプのサイズと構造内の特定のサブビューのオフセットを知る必要があるということです。 たとえば、メモリを割り当てる関数に型サイズを渡すことができます。

残念ながら、型のサイズはプラットフォームによって大きく異なる可能性があります。ポインターのサイズは最も単純な例です。 このような問題を解決するスマートな方法は、getelementptrステートメントを使用することです 。

10.3.2。 ガベージコレクタースタックフレーム

一部の言語は、多くの場合、ガベージコレクターの存在や、クロージャーの実装を容易にするために、スタックフレームを明示的に制御することを望んでいます。 多くの場合、これらの機能を実装するには、明示的なスタックフレーム管理よりも優れた方法がありますが、LLVMは必要に応じてこれをサポートしています。 これを行うには、フロントエンドでコードをContinuation Passing Styleに変換し、テールコール（LLVMもサポート）を使用する必要があります。