|
サイトマップ
ダウンロード！ このサイトを検索 役立つリンク リリースメール によって管理 llvm-adminチーム |
オープンLLVMプロジェクト
Google Summer of Code 2024の候補学生の皆さん、ようこそ！このドキュメントは、LLVM、Clang、およびその他の関連サブプロジェクトの興味深く重要なプロジェクトを見つけるための出発点です。このプロジェクトのリストは、Google Summer of Codeのために開発されただけでなく、開発者による作業を必要とし、LLVMコミュニティにとって非常に有益なオープンプロジェクトでもあります。 このリストを見て、どのプロジェクトがあなたの興味をそそり、あなたのスキルセットとよく一致するかを確認することをお勧めします。また、このリストにない提案も歓迎します。GSoCに関する詳細情報と議論は、discourseにあります。特定のプロジェクトについて質問がある場合は、discourseで関連するエントリを見つけ、以前の議論を確認し、質問してください。そのようなエントリがない場合や、アイデアを提案したい場合は、新しいエントリを作成してください。コミュニティからのフィードバックは、提案が検討され、できれば承認されるための要件です。 LLVMプロジェクトは、Google Summer of Codeに数年間参加しており、非常に成功したプロジェクトもいくつかありました。今年はそれと変わらず、皆さんの提案を楽しみにしています。提案の提出方法については、Google Summer of CodeのメインWebサイトをご覧ください。 プロジェクトの説明： LLVMの多くの単体テストは、より大きなテストから自動的に削減されています。以前の世代の削減ツールでは、undefとpoisonをすべての場所でプレースホルダーとして使用し、未定義の動作（UB）も導入しました。UBを含むテストは、1）将来、コンパイラがより積極的に最適化を開始してテストが中断する可能性があるため脆弱であり、2）Alive2などの翻訳検証ツールを壊してしまうため（常にUBになる関数を何かに翻訳することは正しいので）、望ましくありません。
期待される結果：LLVMの単体テストの大部分はUBがなくなります。 スキル：スクリプト（PythonまたはPHP）の経験が必要です。正規表現の経験を推奨します。 プロジェクトサイズ：中または大。 難易度：中 確認済みのメンター：Nuno Lopes Discourse：URL プロジェクトの説明: LLVM に存在する SPIR-V 命令セットを記述した既存のファイルは手動で作成されており、必ずしも完全または最新ではありません。新しい命令を SPIR-V バックエンドに追加する必要があるたびに、ファイルを修正する必要があります。さらに、体系的な方法で作成されていないため、SPIR-V 仕様で命令が記述されている方法と、TableGen ファイルで宣言されている方法との間にわずかな不一致が生じることがよくあります。SPIR-V バックエンドの開発者は、新しい機能を開発する際に仕様を参考にするため、仕様と TableGen レコードの一貫したマッピングがあると、開発が容易になります。このプロジェクトでは、KhronosGroup/SPIRV-Headers リポジトリで利用可能な JSON 文法に基づいて、SPIR-V 命令セットを記述した完全な TableGen ファイルを生成できるスクリプトを作成し、新しい定義を使用するように SPIR-V バックエンド コードを更新することを提案します。JSON 文法を TableGen に変換する具体的な方法は、応募者の裁量に任されますが、将来のメンテナーが文法が変更されたときにファイルを再生成できるように、翻訳プロセスを再現するための十分に文書化された手順とともに LLVM リポジトリにチェックインする必要があります。文法自体は、既存の別のリポジトリでは out-of-tree のままにする必要があることに注意してください。 期待される結果
スキル: スクリプト作成の経験と C++ の中級程度の知識。LLVM/TableGen の経験があればボーナスですが、必須ではありません。 プロジェクト規模: 中規模 (175 時間) 確定済みのメンター: Natalie Chouinard、Nathan Gauër Discourse: URL プロジェクトの説明: LLVM ビットストリーム ファイル形式は、LLVM IR や Clang モジュールなどの中間コンパイラ成果物をシリアライズするために使用されます。複数のビットストリーム ファイルが同一の情報を保存している場合があり、この重複によってストレージ要件が増加します。 期待される結果: CAS をバッキング ストレージとして使用するように LLVM ビットストリーム ライター/リーダーを設定する方法がある。 スキル: C++ の中級程度の知識、データシリアライゼーションに関するある程度の知識、自己動機。 プロジェクト規模: 中規模または大規模 確定済みのメンター: Jan Svoboda、Steven Wu Discourse: URL プロジェクトの説明: 3方向比較は、値が小さい、等しい、または大きいかを比較した結果に応じて、-1、0、または 1 の値を返します。これらは C++ では宇宙船演算子 (operator<=>) を介して、Rust では PartialOrd および Ord トレイトを介して公開されます。現在、このような比較では、場合によっては最適化されていないコード生成と最適化結果が生成されます。
期待される結果: バックエンドと最も重要な最適化パスでのイントリンシックのサポート。理想的には、フロントエンドから始まる完全な統合。 スキル: C++ の中級程度の知識 プロジェクト規模: 中規模または大規模 難易度：中 確定済みのメンター: Nikita Popov、Dhruv Chawla Discourse: URL プロジェクトの説明: llvm.org のウェブサイトは、LLVM プロジェクトに関する情報の中心的なハブとして機能し、プロジェクトの詳細、最新のイベント、および関連リソースを網羅しています。時間の経過とともに、ウェブサイトは有機的に進化しており、その現代性、構造、および保守の容易さを向上させるための再設計が必要となっています。 期待される結果: 新規ユーザーを惹きつけ、既存のコミュニティに、より良いナビゲーション、分類、コンテンツの発見可能性、および全体的なユーザビリティを提供できる、現代的で一貫性のある外観のウェブサイト。ウェブサイトは重要なインフラストラクチャであり、コミュニティのほとんどが意見を持つため、このプロジェクトでは、実施されている手順に関するコミュニティのコンセンサスを構築するために、コミュニティとの連携を試みる必要があります。推奨されるアプローチ
スキル: 静的サイトジェネレーターを使用したウェブ開発の分野での知識。html、css、bootstrap、および markdown の知識。忍耐と自己動機。 難易度: 難しい プロジェクト規模: 大規模 確定済みのメンター: Tanya Lattner、Vassil Vassilev Discourse: URL プロジェクトの説明: Clang コンパイラは、LLVM コンパイラ インフラストラクチャの一部であり、C、C++、ObjC、ObjC++ などのさまざまな言語をサポートしています。LLVM と Clang の設計により、ライブラリとして使用できるようになり、ツールによるコンパイラ支援のエコシステム全体が作成されました。Clang の比較的使いやすいコードベースと、LLVM における JIT インフラストラクチャの進歩により、コンパイル時と実行時の境界線を曖昧にすることで、C++ を処理するためのさまざまな方法の研究がさらに可能になりました。課題としては、インクリメンタルコンパイルや、より動的な環境へのコンパイル/リンク時最適化の適合などが挙げられます。 期待される結果: Clang-Repl によるステートメントのアウトオブプロセス実行を実装する。Clang-Repl が一部の ez-clang ユースケースをサポートできることを実証する。クラッシュ時にセッションを再開/継続する方法を研究する。ストレッチゴールとして、クラッシュ回復のための汎用性の高い信頼性アプローチを設計する。 スキル: C++ の中級程度の知識、特に LLVM と LLVM JIT の理解 プロジェクト規模: 中規模または大規模 難易度：中 確定済みのメンター: Vassil Vassilev Discourse: URL プロジェクトの説明: Clang コンパイラは、LLVM コンパイラ インフラストラクチャの一部であり、C、C++、ObjC、ObjC++ などのさまざまな言語をサポートしています。LLVM と Clang の設計により、コンパイラをプラグインで拡張できるようになっています[1]。プラグインを使用すると、コンパイル中にユーザー定義の追加アクションを実行できます。プラグインは Unix および Darwin でサポートされていますが、Windows プラットフォームのいくつかの特殊性により、Windows ではサポートされていません。 期待される結果: このプロジェクトでは、clang -fplugin=windows/plugin.dll を機能させることを目的としています。実装アプローチでは、機能しているプロトタイプ[3]を拡張し、アノテーションツール[4]を拡張する必要があります。成功した候補者は、毎週の会議に出席し、プレゼンテーションを行い、要求に応じてブログ投稿を準備する用意をする必要があります。 詳細な読み物 スキル: C++ の中級程度の知識、Windows およびそのコンパイルとリンクモデルの経験。 プロジェクト規模: 中規模または大規模 難易度：中 確定済みのメンター: Vassil Vassilev、Saleem Abdulrasool Discourse: URL プロジェクトの説明: Clang は、他の C++ コンパイラと同様に、文字がリニアに表示されると、その文字のシーケンスを解析します。その後、リニア文字シーケンスはトークンと AST に変換され、マシンコードに下げられます。多くの場合、エンドユーザーのコードは翻訳単位全体からの C++ エンティティのごく一部を使用しますが、ユーザーは冗長なすべてをコンパイルする代償を支払います。 // A.h
#include <string>
#include <vector>
template <class T, class U = int> struct AStruct {
void doIt() { /*...*/ }
const char* data;
// ...
};
template<class T, class U = AStruct<T>>
inline void freeFunction() { /* ... */ }
inline void doit(unsigned N = 1) { /* ... */ }
// Main.cpp
#include "A.h"
int main() {
doit();
return 0;
}
この病的な例では、処理するために37253行のコードに展開されます。Clingは、これらのC++エンティティの前方宣言のみを含むインデックス（オートローディングマップと呼んでいます）を作成します。そのサイズは3000行のコードです。インデックスは次のようになります。 // A.h.index
namespace std{inline namespace __1{template <class _Tp, class _Allocator> class __attribute__((annotate("$clingAutoload$vector"))) __attribute__((annotate("$clingAutoload$A.h"))) __vector_base;
}}
...
template <class T, class U = int> struct __attribute__((annotate("$clingAutoload$A.h"))) AStruct;
エンティティの完全な型が必要になると、Clingはそれを得るために関連するヘッダーファイルをインクルードします。デフォルト引数とデフォルトテンプレート引数は、前方宣言と定義の両方に現れるため、それらに対処するためのいくつかの簡単な回避策があります。詳細については、[1]を参照してください。 この実装は参照実装とは呼べませんが、Clangのパーサーとプリプロセッサは比較的ステートレスであり、線形ではない性質の文字シーケンスを処理するために使用できることを示しています。特に、名前空間スコープの定義は比較的簡単に処理でき、何かを遅延解析するときに名前空間スコープに戻ることはそれほど難しくありません。ローカルクラスなどの他のコンテキストでは、ローカルエンティティの名前ルックアップテーブルなど、いくつかの重要な情報が失われます。ただし、これらのケースは、遅延解析の粒度がトップレベルのエンティティでのみ行う価値があるため、おそらくあまり興味深いものではありません。 このような実装は、クラスの遅延部分が最初に必要になったときに、その最初の使用がクラスの終了よりも前である場合、すぐに解析されるという、標準における既存の問題であるCWG2335などの問題を解決するのに役立ちます。これは、囲みスコープに戻って何かを解析するために必要なすべての操作をアップストリームするのに十分な動機付けになるはずです。 実装アプローチ：解析中にタグ定義が見つかったら、前方宣言を作成し、トークンシーケンスを記録して、遅延定義としてマークできます。後で完全な型のリクエストがあったら、パーサーの位置を定義本体を解析するように再設定できます。同様の方法で、すでにいくつかのテンプレート特殊化をスキップしています[2, 3]。 別の方法としては、遅延解析されたすべてのエンティティがそのトークンストリームを記録し、LateParsedDeclarationsに格納されたToksを、独自のシーケンスを格納する代わりに、外部に格納されたトークンシーケンスのサブシーケンスをオプションで参照するように変更します（またはCachedTokensを変更して、透過的に実行できるようにすることもできます）。課題の1つは、現在、キャッシュされたトークンリストに「eof」トークンを追加するために変更していることですが、これは別の方法で処理できるはずです。 場合によっては、クラス定義が周囲のコンテキストにいくつかの影響を与える可能性があり、ここでは注意が必要です。 1）クラス内に現れる`struct X`は、囲みコンテキストに名前`X`を導入できます。 2）`static inline`宣言は、任意の副作用を持つ可能性のある非定数初期化子を持つグローバル変数を導入できます。 （2）の点については、より一般的な問題があります。任意の式の解析は、副作用を持つ初期化子を持つ静的データメンバーを持つクラステンプレートのテンプレートインスタンス化をトリガーする可能性があります。上記の2つのケースとは異なり、トークンストリームの簡単な分析によってそのようなケースを正しく検出および処理する方法はないと思います。このようなケースを検出するには、実際のセマンティック分析が必要です。しかし、もしそれらが使用されていないコードでのみ発生する場合は、Clangにそのようなインスタンス化が実際に発生することを保証しない言語モードがあっても、それほどひどいことではないでしょう。 代替のより効率的な実装は、ルックアップテーブルを範囲ベースにすることですが、これが実行可能なアプローチであることを証明するプロトタイプさえありません。 期待される結果
詳細な読み物 スキル: C++の知識、Clangの動作に関する深い理解、Clang ASTとプリプロセッサの知識。 プロジェクトの規模: 大 難易度: 難しい 確定メンター: Vassil Vassilev、Matheus Izvekov ディスカッション: URL プロジェクトの説明: Clang-Docは、Doxygenの代替として作成され、LibToolingの上に構築されたC/C++ドキュメント生成ツールです。この取り組みは2018年に開始され、2019年に重要な要素が導入されましたが、主にリソースの不足により、その後の開発はほとんど休止状態になっています。
期待される結果: このプロジェクトの目標は、既存の欠点に対処し、Clang-Docのユーザビリティを、LLVMなどの大規模プロジェクトのドキュメントを生成するために使用できるレベルまで改善することです。理想的な成果は、LLVMプロジェクトがリファレンスドキュメントの生成にClang-Docを使用することです。 スキル: Webテクノロジー（HTML、CSS、JS）の経験と、C++の中級レベルの知識。Clang/LibToolingの以前の経験はボーナスですが、必須ではありません。 プロジェクトサイズ：中または大。 難易度：中 確定メンター: Petr Hosek、Paul Kirth ディスカッション: URL 説明 デバッグ情報からの変数ロケーション情報を使用して、LLDBの逆アセンブラ（および`register read`）の出力に、ソース変数の場所と寿命を注釈します。リッチ逆アセンブラの出力は構造化データとして公開され、LLDBのスクリプトAPIを介して利用できるようにすることで、より多くのツールを構築できるようにする必要があります。ターミナルでは、LLDBは注釈をテキストとしてレンダリングする必要があります。 期待される成果 たとえば、次の関数の逆アセンブリを拡張できます。frame #0: 0x0000000100000f80 a.out`main(argc=1, argv=0x00007ff7bfeff1d8) at demo.c:4:10 [opt]
1 void puts(const char*);
2 int main(int argc, char **argv) {
3 for (int i = 0; i < argc; ++i)
→ 4 puts(argv[i]);
5 return 0;
6 }
(lldb) disassemble
a.out`main:
...
0x100000f71 <+17>: movl %edi, %r14d
0x100000f74 <+20>: xorl %r15d, %r15d
0x100000f77 <+23>: nopw (%rax,%rax)
→ 0x100000f80 <+32>: movq (%rbx,%r15,8), %rdi
0x100000f84 <+36>: callq 0x100000f9e ; symbol stub for: puts
0x100000f89 <+41>: incq %r15
0x100000f8c <+44>: cmpq %r15, %r14
0x100000f8f <+47>: jne 0x100000f80 ; <+32> at demo.c:4:10
0x100000f91 <+49>: addq $0x8, %rsp
0x100000f95 <+53>: popq %rbx
...
LLDBもアクセスできるデバッグ情報を使用して（ソース変数iが[0x100000f77 + スライド]からr15にあることを確認してください）。 $ dwarfdump demo.dSYM --name i
demo.dSYM/Contents/Resources/DWARF/demo: file format Mach-O 64-bit x86-64
0x00000076: DW_TAG_variable
DW_AT_location (0x00000098:
[0x0000000100000f60, 0x0000000100000f77): DW_OP_consts +0, DW_OP_stack_value
[0x0000000100000f77, 0x0000000100000f91): DW_OP_reg15 R15)
DW_AT_name ("i")
DW_AT_decl_file ("/tmp/t.c")
DW_AT_decl_line (3)
DW_AT_type (0x000000b2 "int")
次のような出力を作成します。ここで、変数が有効なときと、その場所を注釈します。(lldb) disassemble a.out`main: ... ; i=0 0x100000f74 <+20>: xorl %r15d, %r15d ; i=r15 0x100000f77 <+23>: nopw (%rax,%rax) ; | → 0x100000f80 <+32>: movq (%rbx,%r15,8), %rdi ; | 0x100000f84 <+36>: callq 0x100000f9e ; symbol stub for: puts ; | 0x100000f89 <+41>: incq %r15 ; | 0x100000f8c <+44>: cmpq %r15, %r14 ; | 0x100000f8f <+47>: jne 0x100000f80 ; <+32> at t.c:4:10 ; | 0x100000f91 <+49>: addq $0x8, %rsp ; i=undef 0x100000f95 <+53>: popq %rbx 目標は、たとえば、定数である変数や完全にレジスタにある変数など、曖昧さのないケースのサブセットに対してこのような出力を生成することです。 確定済みのメンターとその連絡先
必要なスキル/望ましいスキル 必須
望ましい
プロジェクトの規模。 中（〜175時間） 可能であれば、簡単、中、難しいの評価 難しい ディスカッション: URL 説明 LLVM-reduceおよび同様のツールはデルタデバッグを実行しますが、多くの暗黙的な制約が存在し、違反すると分離対象である原因に類似したエラーが発生しやすいため、あまり役に立ちません。このプロジェクトは、特に実行時バグについて、GPU対応バージョンを開発することです。これは、LLVM/OpenMP GPUレコードアンドリプレイ、または単純にGPUローダースクリプトと組み合わせて使用して、GPUテストケースをより効率的かつ効果的に最小化するために使用できます。 期待される成果 元のエラーを失うことなくGPUエラーを減らすためのツール。オプションで、エラーだけでなく、他のプロパティを削減の焦点にすることもできます。 確定済みのメンターとその連絡先
必要なスキル/望ましいスキル 必須
望ましい
プロジェクトの規模。 中 可能であれば、簡単、中、難しいの評価 中 ディスカッション: URL 説明 現代のC++では、並列アルゴリズムが標準ライブラリの一部として定義されています。例:`std::transform_reduce(std::execution::par_unseq, vec.begin(), vec.end(), 0, std::plus` 期待される成果 libcxxでのオフロードのプロトタイプサポートの改善。他のオフロードアプローチに対する評価と、欠落している部分と欠点に関するドキュメント。 確定済みのメンターとその連絡先
必要なスキル/望ましいスキル 必須
望ましい
プロジェクトの規模。 大 可能であれば、簡単、中、難しいの評価 中 ディスカッション: URL 説明 LLVMには、「コストの高いケース」を避けるための閾値やフラグがたくさんあります。しかし、これらの閾値が有用なのか、その値が妥当なのか、そして実際にどのような影響があるのかは不明確です。数が多いため、単純な総当たり検索はできません。いくつかのプロトタイプ作業では、ハードコードされた値を置き換え、閾値を制御できるC++クラスを導入しました。例えば、コマンドラインフラグを使って、ハードコードされた「6」という再帰制限を別の数値に増やすことができます。このプロジェクトでは、閾値がいつヒットするのか、ヒットした場合に何が起こるのか、どのように値を選択すべきか、そして異なる「プロファイル」が必要かどうかを調査します。 期待される成果 LLVMのコードベース内の様々な閾値の影響に関する統計的証拠。これには、コンパイル時間の変化、変換への影響、およびパフォーマンス測定が含まれます。 確定済みのメンターとその連絡先
必要なスキル/望ましいスキル 必須
望ましい
プロジェクトの規模。 中 可能であれば、簡単、中、難しいの評価 簡単 ディスカッション: URL 説明 GPUをターゲットとしたlibcライブラリの開発を開始しました。これにより、ユーザーはGPU上で実行中にmallocやmemcpyなどの関数を呼び出すことができます。ただし、これらの実装は機能的で高性能であることが重要です。このプロジェクトの目標は、GPU上での特定のlibc関数の実装をベンチマークすることです。これには、現在の実装をテストするためのベンチマークの作成や、より最適な実装の作成が含まれます。 期待される成果 libc関数の詳細なパフォーマンス。GPUからCPUへのリモートプロシージャコールのオーバーヘッド。「libc」関数のより最適な実装。 確定済みのメンターとその連絡先
必要なスキル/望ましいスキル 必須
望ましい
プロジェクトの規模。 小 可能であれば、簡単、中、難しいの評価 簡単 ディスカッション: URL 説明 GPU Firstは、既存のホストコードをユーザーが変更することなく、プログラム全体をGPU上で実行できるようにする手法とフレームワークです。このプロジェクトの目標は2つあります。1) ホストコードを移植して、新しいプラグインへのRPCを処理し、GPU LibCプロジェクトで導入されたホストRPCフレームワークで書き換えること。2) 単一GPU上、または複数のGPU上での複数のスレッドブロック間でのMPIのサポートを調査すること。 期待される成果 NVIDIAとAMDの両方のGPUをサポートできる、より効率的なGPU Firstフレームワーク。オプションで、フレームワークをアップストリームする。 確定済みのメンターとその連絡先
必要なスキル/望ましいスキル 必須
望ましい
プロジェクトの規模。 中 可能であれば、簡単、中、難しいの評価 中 ディスカッション: URL 説明: SYCL、OpenMP、OpenACCなどの異種プログラミングモデルは、開発者が計算負荷の高いカーネルをGPUやその他のアクセラレータにオフロードするのに役立ちます。MLIRは、異種プログラミングモデル向けの次世代コンパイラに対して、新しい高レベルの最適化とより良いコード生成を解き放つことが期待されています。しかし、堅牢なMLIR出力C/C++フロントエンドの利用可能性は、これらの取り組みの前提条件です。 ClangIR (CIR) プロジェクトは、Clangの新しい中間表現 (IR) を確立することを目的としています。MLIRの上に構築されており、Clang内のC/C++ベースの言語のダイアレクトと、Clang ASTからの出力に必要なインフラストラクチャ、およびLLVM-IRダイアレクトへの低減パスを提供します。昨年、ClangIRは成熟したインキュベータープロジェクトに進化し、最近のRFCでLLVMモノリポジトリへのアップストリームが肯定的なコメントとコミュニティサポートを得ています。 このGSoCプロジェクトの全体的な目標は、OpenCL C言語でGPUカーネルをSPIR-VターゲットのLLVM-IRにコンパイルできるようにするために、ClangIRに不足している機能を特定して実装することです。OpenCLからSPIR-Vへのフローは、a) Clangですでにサポートされており、b) OpenCLのワークアイテムベースおよびワークグループベースのプログラミングモデルが依然として最新のGPUアーキテクチャをうまく捉えているため、このプロジェクトにとって最適な環境です。コントリビューターは、ASTビジター、ダイアレクト、およびLLVM-IR低減を拡張して、複数のアドレス空間、ベクトル型、カスタム浮動小数点型、および この作業の良い出発点は、Polybench-GPUベンチマークスイートです。これには、一般的なアルゴリズムの自己完結型の小規模から中規模のOpenCL実装が含まれています。ClangIR経由でコンパイルされるのは、デバイスコード(*.clファイル) のみです。Clangの既存のOpenCLサポートを使用して、開発をガイドするための参照LLVM-IR出力を使用したリテラルトテストを作成できます。オプションで、Polybenchの組み込み結果検証と時間測定を使用して、生成されたコードの正確性と品質を評価することもできます。 期待される結果: Polybench-GPUの スキル: 中級のC++プログラミングスキルと、基本的なコンパイラ設計の概念に関する知識が必要です。LLVM IR、MLIR、Clang、またはGPUプログラミングの経験があると非常に有利ですが、学ぶ意欲も可能です。 プロジェクト規模: 大規模 難易度：中 確認済みのメンター: Julian Oppermann、Victor Lomüller、Bruno Cardoso Lopes ディスカッション: URL 説明 半精度は、特に機械学習とAIで最近広く使用されているIEEE 754浮動小数点形式です。最新のC23標準で_Float16として標準化され、floatやdoubleデータ型と同じレベルのサポートが提供されています。このプロジェクトの目標は、LLVM libcライブラリにC23半精度数学関数を実装することです。 期待される結果
スキル 中級のC++プログラミングスキルと、基本的なコンパイラ設計の概念に関する知識が必要です。LLVM IR、MLIR、Clang、またはGPUプログラミングの経験があると非常に有利ですが、学ぶ意欲も可能です。 プロジェクト規模: 大規模 難易度: 簡単/中 確認済みのメンター: Tue Ly、Joseph Huber ディスカッション: URL Google Summer of Code 2023は、LLVMプロジェクトにとって非常に成功しました。受け入れられ完了したプロジェクトのリストについては、Google Summer of Codeのウェブサイトをご覧ください。 プロジェクトの説明: ジャストインタイムコンパイラでは、コンパイル時間を最小限に抑え、起動時間とレイテンシを改善するために、低い最適化レベルを選択することがよくあります。ただし、一部の関数 (ホット関数と呼びます) は非常に頻繁に使用され、これらの関数についてはより徹底的な最適化を行う価値があります。一般に、ホット関数は実行時 (異なる入力によって、ホットになる関数が異なる) にのみ識別できるため、再最適化プロジェクトの目的は、(1) 実行時にホット関数を検出し、(2) より高い最適化レベルで2回目にコンパイルするインフラストラクチャを構築することです。これが「再最適化」と呼ばれる理由です。 期待される結果
望ましいスキル: 中級のC++; LLVM、特にLLVM JITの理解。 プロジェクトサイズ: 大規模。 難易度：中 確認済みのメンター: Vassil Vassilev、Lang Hames ディスカッション: URL プロジェクトの説明: JITLinkは、LLVMの新しいJITリンカーAPIです。これは、コンパイラの出力 (再配置可能なオブジェクトファイル) をメモリ内の実行可能なバイトに変換する低レベルAPIです。これを行うために、JITLinkの汎用リンカーアルゴリズムは、ターゲットオブジェクト形式 (COFF、ELF、MachO) およびアーキテクチャ (arm、arm64、i386、x86-64) をサポートするように特殊化する必要があります。LLVMには、MachO/arm64、MachO/x86-64、ELF/x86-64、ELF/aarch64、およびCOFF/x86-64向けのJITLinkの成熟した実装がすでにありますが、ELF/riscv、ELF/aarch32、およびCOFF/i386の実装は比較的新しいものです。 期待される結果: PowerPC、AArch32、またはeBPFなど、まだサポートされていない、または不完全な形式/アーキテクチャのJITLink特殊化を記述します。 望ましいスキル: 中級のC++; LLVM、特にLLVM JITの理解; 選択した形式/アーキテクチャに関する知識、および基本的なリンカーの概念 (セクション、シンボル、再配置など)。 プロジェクトサイズ: 大規模。 難易度: 中 確認済みのメンター: Vassil Vassilev、Lang Hames Stefan Gränitzディスカッション: URL プロジェクトの説明: コンパイラの主な仕事は高速なコード (優れた実行時パフォーマンス) を生成することですが、最適化に時間がかかりすぎないこと (優れたコンパイル時パフォーマンス) も重要です。このプロジェクトの目標は、最適化の品質を損なうことなくコンパイル時間を改善することです。
期待される結果: いくつかの個々のファイルで大幅な改善（数パーセント）、および全体の幾何平均コンパイル時間のわずかな改善。 望ましいスキル: 中級レベルのC++。プロファイリングツールの知識（特にLinuxを使用していない場合は、私がサポートできないため、特に重要です）。 プロジェクトサイズ：中または大。 難易度：中 メンターの確認: Nikita Popov ディスカッション: URL プロジェクトの説明: Rustプログラミング言語はコード生成にLLVMを使用しており、LLVMの最適化機能に大きく依存しています。しかし、rustcによって生成される典型的なコードパターンをLLVMが最適化できないケースが多数存在します。このような問題は、I-slow および/または A-LLVM ラベルを使用して報告されています。
期待される結果: 簡単から中程度のRustの最適化の失敗に対する修正。修正が実装されなかった場合でも、いくつかの失敗に対する予備的な分析。 望ましいスキル: 実装には中級レベルのC++。分析にはLLVMの知識（少なくともLLVM IRを理解する能力）。基本的なRustの知識（Rustコードを読める程度で、書く必要はない）。 プロジェクトサイズ：中または大。 難易度：中 メンターの確認: Nikita Popov ディスカッション: URL プロジェクトの説明: Clang コンパイラは、LLVM コンパイラ インフラストラクチャの一部であり、C、C++、ObjC、ObjC++ などのさまざまな言語をサポートしています。LLVM と Clang の設計により、ライブラリとして使用できるようになり、ツールによるコンパイラ支援のエコシステム全体が作成されました。Clang の比較的使いやすいコードベースと、LLVM における JIT インフラストラクチャの進歩により、コンパイル時と実行時の境界線を曖昧にすることで、C++ を処理するためのさまざまな方法の研究がさらに可能になりました。課題としては、インクリメンタルコンパイルや、より動的な環境へのコンパイル/リンク時最適化の適合などが挙げられます。 [clang-repl] class MyLongClassName {};
[clang-repl] My<tab>
// list of suggestions.
期待される結果: 複数のタスクが想定されます。
プロジェクト規模: 大規模。 難易度：中 メンターの確認: Vassil Vassilev ディスカッション: URL プロジェクトの説明: 現在、Clangは各 Clangには、明示的にビルドされたモジュールという、モジュールをビルドする別の方法がありますが、現在、採用するにはビルドシステムの変更が必要です。ここでは、ビルドシステムが、例えば clang-scan-deps を使用して、どのモジュールが必要かを判断し、それらのモジュールを必要とする この新しいモジュールビルド方法を、ビルドシステムの大きな変更なしに採用できるようにするために、モジュールビルドデーモンが必要です。コマンドラインに小さな変更を加えるだけで、clangはこのデーモンに接続し、必要なモジュールを要求します。モジュールビルドデーモンは、既存の有効なモジュールを返すか、ビルドしてから返します。 llvm-projectフォークには、既存のオープンソースの依存関係スキャンデーモンがあります。これはファイル依存関係のみを処理しますが、IPCメカニズムがあります。このIPCシステムをモジュールビルドデーモンのベースとして使用できますが、Windowsで動作するように拡張する必要があります。 期待される結果: 既存のビルドシステム（MakeやCMakeなど）を使用するClangモジュールを使用する通常のプロジェクトを、モジュールビルドデーモンを介して明示的にビルドされたモジュールのみを使用してビルドできます。 望ましいスキル: 中級レベルのC++プログラミングスキル。コンパイラの知識。Clangの知識はあれば有利ですが、必須ではありません。 プロジェクト規模: IPCの再利用に応じて175時間または350時間 難易度: 中程度 メンターの確認: Michael Spencer, Jan Svoboda ディスカッション: URL プロジェクトの説明: Swift-DocC は、Swift OSSプロジェクトの公式ドキュメントコンパイラです。ただし、Swift-DocCはSwiftに固有のものではなく、SymbolKit の言語に依存しないJSONベースのシンボルグラフ形式を使用して、コードで使用可能なシンボルを理解します。これにより、シンボルグラフジェネレーターがあれば、どの言語でもSwift-DocCでサポートできます。 Clangは、[RFC] clang support for API information generation in JSON で説明されているように、CおよびObjective-Cのシンボルグラフ生成をサポートしています。現在、Objective-Cカテゴリのサポートは完全ではありません。一方では、カテゴリが現在のモジュールの型を拡張する場合、カテゴリメンバーは拡張された型自体に属すると見なされます。他方では、拡張された型が別のモジュールに属する場合、カテゴリは無視されます。それにもかかわらず、モジュールの公開APIの一部として、Objective-Cの他のモジュールに属する型を拡張することは一般的です。このプロジェクトの目標は、Objective-Cカテゴリに対応するためにシンボルグラフ形式を拡張し、clangとlibclangの両方を介してこの情報を生成するサポートを実装することです。 期待される結果: 他のモジュールで定義されたシンボルのカテゴリを記述するために、clangのシンボルグラフジェネレーターとlibclangに必要なサポートを追加します。これには、そのコミュニティと議論する必要があるSymbolKitへの追加が含まれる可能性があります。 望ましいスキル: 中級レベルのC++プログラミングスキル。clangとObjective-Cの知識はあれば有利ですが、必須ではありません。 プロジェクト規模: 中規模 難易度：中 メンターの確認: Daniel Grumberg, Zixu Wang, Juergen Ributzka ディスカッション: URL プロジェクトの説明: Swift-DocC は、Swift OSSプロジェクトの公式ドキュメントコンパイラです。ただし、Swift-DocCはSwiftに固有のものではなく、SymbolKit の言語に依存しないJSONベースのシンボルグラフ形式を使用して、コードで使用可能なシンボルを理解します。これにより、シンボルグラフジェネレーターがあれば、どの言語でもSwift-DocCでサポートできます。 Clangは、[RFC] clang support for API information generation in JSON で説明されているように、CおよびObjective-Cのシンボルグラフ生成をサポートしています。 現在、出力されるシンボルグラフ形式は、テンプレートや例外などのさまざまなC++構文をサポートしておらず、シンボルグラフジェネレーターはC++を完全に理解していません。このプロジェクトは、シンボルグラフ形式にさまざまなC++構文のサポートを導入し、clangでこのデータを生成するサポートを実装することを目的としています。 期待される結果: 他のモジュールで定義されたシンボルのカテゴリを記述するために、clangのシンボルグラフジェネレーターとlibclangに必要なサポートを追加します。これには、そのコミュニティと議論する必要があるSymbolKitへの追加が含まれます。 望ましいスキル: 中級レベルのC++プログラミングスキル。clangとObjective-Cの知識はあれば有利ですが、必須ではありません。 プロジェクト規模: 大規模 難易度: 中程度/難しい メンターの確認: Daniel Grumberg, Zixu Wang, Juergen Ributzka ディスカッション: URL プロジェクトの説明: Swift-DocC は、Swift OSSプロジェクトの公式ドキュメントコンパイラです。ただし、Swift-DocCはSwiftに固有のものではなく、SymbolKit の言語に依存しないJSONベースのシンボルグラフ形式を使用して、コードで使用可能なシンボルを理解します。これにより、シンボルグラフジェネレーターがあれば、どの言語でもSwift-DocCでサポートできます。 Clangは、[RFC] clang support for API information generation in JSON で説明されているように、CおよびObjective-Cのシンボルグラフ生成をサポートしています。 現在、ユーザーは 期待される結果: 通常のコンパイル（またはモジュールビルド）中にシンボルグラフファイルを生成できるようにします。個々のオブジェクトファイルを静的リンカーがリンクするのと同じ方法でシンボルグラフファイルをマージするツールを提供します。シンボルグラフファイルに含まれるすべての情報をサポートするようにclang Indexを拡張します。 望ましいスキル: 中級レベルのC++プログラミングスキル。clangとObjective-Cの知識はあれば有利ですが、必須ではありません。 プロジェクト規模: 中規模 難易度: 中程度/難しい メンターの確認: Daniel Grumberg, Zixu Wang, Juergen Ributzka ディスカッション: URL 説明: clangが出力する診断メッセージは、開発者へのインターフェースです。診断メッセージは一般的に優れていますが、改善が必要な点がいくつかあります。いくつかのケースは、コンパイラーで特別な処理をすることで改善できます。 Clangの問題追跡ツールからわかるように、clangの診断メッセージに対して、多くの問題が未解決のままになっています。 このプロジェクトは、1つの大きな機能を実装することを目的とするのではなく、Clangの診断メッセージに対する小さく、段階的な改善に焦点を当てています。 解決可能な問題の例:
期待される成果: 少なくとも3つの小規模な診断に関する問題を修正、または1つの大規模な診断の改善を実装すること。 確定メンター:Timm Bäder 望ましいスキル
プロジェクトタイプ: 中規模/200時間 ディスカッション URL 説明: ClangコンパイラはLLVMコンパイラインフラストラクチャの一部であり、C、C++、ObjC、ObjC++などのさまざまな言語をサポートしています。LLVMとClangの設計により、ライブラリとして使用することができ、コンパイラ支援によるツールエコシステム全体の作成につながっています。Clangの比較的親しみやすいコードベースと、LLVMのJITインフラストラクチャの進歩により、コンパイル時とランタイムの境界を曖昧にすることで、C++を処理するためのさまざまな方法の研究をさらに進めることができます。課題には、インクリメンタルコンパイルと、コンパイル/リンク時の最適化をより動的な環境に適合させることが含まれます。 インクリメンタルコンパイルパイプラインは、翻訳ユニットを拡張しながら、コードをチャンクごとに処理します。その後、コードはLLVM IRに低レベル化され、LLVM JITによって実行されます。このようなパイプラインは、効率的なインタープリターの作成を可能にします。このインタープリターにより、インタラクティブな探索が可能になり、C++言語がよりユーザーフレンドリーになります。インクリメンタルコンパイルモードは、もともとC++環境でのインタラクティブな高エネルギー物理分析を可能にするために開発されたインタラクティブC++インタープリターであるClingで使用されています。 私たちは、新しいツールであるclang-replを通じて、Clingの一部をClangメインラインに組み込み、場合によっては再設計する取り組みを行っています。このプロジェクトは、プロジェクトの機能をデモンストレーションするチュートリアルを実装し、JupyterでC++を記述できるようにするxeus-clang-replプロトタイプでのclang-replの採用を調査することを目指しています。 期待される結果: 複数のタスクが想定されます。
確定メンター: Vassil Vassilev David Lange 望ましいスキル: 中級レベルのC++; Clangと特にClang APIの理解 プロジェクトタイプ: 中規模 ディスカッション URL 説明: ClangコンパイラはLLVMコンパイラインフラストラクチャの一部であり、C、C++、ObjC、ObjC++などのさまざまな言語をサポートしています。LLVMとClangの設計により、ライブラリとして使用することができ、コンパイラ支援によるツールエコシステム全体の作成につながっています。Clangの比較的親しみやすいコードベースと、LLVMのJITインフラストラクチャの進歩により、コンパイル時とランタイムの境界を曖昧にすることで、C++を処理するためのさまざまな方法の研究をさらに進めることができます。課題には、インクリメンタルコンパイルと、コンパイル/リンク時の最適化をより動的な環境に適合させることが含まれます。 インクリメンタルコンパイルパイプラインは、増え続ける翻訳単位を構築することにより、コードをチャンクごとに処理します。コードはその後LLVM IRに変換され、LLVM JITによって実行されます。このようなパイプラインにより、効率的なインタープリターを作成できます。インタープリターはインタラクティブな探索を可能にし、C++言語をよりユーザーフレンドリーにします。インクリメンタルコンパイルモードは、xeusカーネルプロトコルを介してJupyterでインタラクティブなC++によって使用されます。プロトコルの新しいバージョンでは、ブラウザ内での実行が可能になり、clang-replとJupyterの可能性がさらに広がります。 私たちは、新しいツールであるclang-replを通じて、Clingの一部をClangメインラインに組み込み、場合によっては再設計する取り組みを行っています。このプロジェクトは、clang-replにWebAssemblyサポートを追加し、JupyterベースのC++を支援するためにxeus-clang-replで採用することを目指しています。 期待される結果: 複数のタスクが想定されます。
確定メンター: Vassil Vassilev Alexander Penev 望ましいスキル: 高度なC++; ClangとClang API、特にLLVM JITの理解 プロジェクトタイプ: 大規模 ディスカッション URL プロジェクトの説明 GNUツールチェーンは、組み込みターゲットを構築するために広く使用されています。Clang/LLVMコミュニティでは、組み込みターゲットをサポートするためにClangツールチェーンを改善する動きがあります。Clangツールチェーンを代替として使用することで、コード品質の向上、セキュリティバグの発見と修正、開発者エクスペリエンスの向上、および組み込みデバイスのサポートにおけるClang/LLVMコミュニティを取り巻く新しいアイデアと勢いを活用することができます。 LLDに対して行える改善の網羅的ではないリスト:
プロジェクト規模: 中規模または大規模 難易度: 中程度/難しい スキル: C++ 期待される結果:
確定メンター: Prabhu Rajasekaran Petr Hosek ディスカッション: URL 説明: MLIRのPresburgerライブラリであるFPL (https://grosser.science/FPL) は、多面体コンパイルと分析のための数学的抽象化を提供します。ライブラリが提供する主な抽象化は、アフィン不等式制約のシステムによって定義された整数のタプルのセットです。このライブラリは、このようなセットに対する標準的な集合演算をサポートしています。結果は、別の制約システムによって定義されたセットになり、おそらくより多くの制約を持つことになります。多くの集合演算が連続して実行されると、制約システムが非常に大きくなり、パフォーマンスに悪影響を与える可能性があります。制約システムを単純化するいくつかの潜在的な方法がありますが、これには追加の計算を実行する必要があります。したがって、より積極的な単純化に多くの時間を費やすと、個々の操作が遅くなる可能性がありますが、同時に、不十分な単純化は、制約システムサイズの爆発のために一連の操作を遅くする可能性があります。このプロジェクトの目的は、両者の適切なバランスを見つけることです。 このプロジェクトの目標
期待される成果:
望ましいスキル: 中級レベルのC++、ベンチマークの経験 プロジェクト規模: 大規模 難易度: 中程度 確定メンター: Kunwar Grover ディスカッション: URL 説明: このプロジェクトは、開発者がMLIR IRを動的にクエリできるようにする、MLIR用のインタラクティブなクエリ言語を開発することを目的としています。このツールは、REPL（またはコマンドライン）インターフェイスを提供し、ユーザーが「isConstant」や「resultOf」などのMLIRコードのさまざまなプロパティをクエリできるようにします。提案されたツールは、clang-queryと同様に、C++コードでAST式を、オートコンプリートなどの機能を備えたTUIを使用してマッチングできるようにすることを目的としています。 このプロジェクトの目標
期待される成果:
望ましいスキル: 中級レベルのC++、ピープホール最適化の作成/デバッグの経験 プロジェクト規模: 中規模または大規模のいずれか。 難易度: 中程度 確定メンター: Jacques Pienaar ディスカッション: URL プロジェクトの説明 実際のデプロイメントでは、レジスタ割り当てのエビクションとインライン化（サイズ用）に、機械学習によるコンパイラ最適化（「MLGO」）を使用しています。MLモデルは、強化学習アルゴリズムを使用してトレーニングされています。より多くのパフォーマンス領域への拡張は現在、パフォーマンス推定モデルの予測品質の低さによって妨げられています。これらを改善することは、強化学習トレーニングアルゴリズムの有効性にとって非常に重要であり、したがって、より多くの最適化にMLGOを体系的に適用することを可能にするために重要です。 プロジェクト規模: 175時間または350時間のいずれか。 難易度：中 スキル: C/C++、コンパイラの経験、Pythonの経験。MLの経験があるとボーナス。 期待される成果: 追加のPMUデータ、LLCミス確率、または分岐予測ミスなどの追加のランタイム/プロファイリング情報を含めることによって、実行環境のモデリングを改善します。これには、(1)追加のランタイム情報をカバーするデータ収集パイプラインの構築、(2)このデータを処理できるようにMLモデルの変更、(3)このデータを利用するようにモデルのトレーニングと推論プロセスを変更することが含まれます。 今日、モデルはほとんど純粋な静的分析です。モデルは命令を確認しますが、コードの実行環境とランタイム動作について、すべてに当てはまる想定を行っています。このプロジェクトの目標は、静的分析から、コードが実際に実行される方法をより良く表す動的モデルに移行することです。 メンター Ondrej Sykora、Mircea Trofin、Aiden Grossman ディスカッション URL プロジェクトの説明: Clang静的アナライザーには、実験的な汚染分析の実装が付属しています。汚染分析は、攻撃者によって制御された（「汚染された」）データの流れを、攻撃者が正しい入力を偽造できる場合、予期しない危険な方法で動作する可能性のある機密関数に警告するように構築された、セキュリティ指向の分析手法です。プログラマーは、これらの危険な入力を排除するために、汚染されたデータを適切に「サニタイズ」することで、そのような警告に対処できます。このようにしてキャッチできる問題の一般的な例は、SQLインジェクションです。はるかに単純な例は、Clangのユーザーにとってより適切である可能性がありますが、攻撃者によって制御された数がスタックまたはヒープ配列を反復処理中にループ境界として使用されたり、次のような低レベルのバッファ操作関数に引数として渡されたりすることによって引き起こされるバッファオーバーフローの脆弱性ですmemcpy(). 静的シンボリック実行エンジンである静的アナライザーは、シンボリックシミュレーション中に既知の汚染源から取得された「シンボル」（名前付きの未知の数値）のリストを保持することで、単純にテイント解析を実装します。このようなシンボルは、取りうる可能性のある値の未知のサブセットを取る一般的なケースとは対照的に、任意の実数値を取りうると潜在的に扱われます。例えば、未チェックの未知の値による除算は、その値がゼロになりうるかどうかが通常不明であるため、必ずしもゼロ除算の警告を必要としません。しかし、未チェックの汚染された値による除算は、攻撃者がゼロを入力として自由に渡すことができるため、直ちにゼロ除算の警告を必要とします。したがって、静的アナライザーのテイントインフラストラクチャはいくつかの部分で構成されています。シンボリックプログラム状態における汚染されたシンボルを追跡するメカニズム、新しい汚染源を定義する方法、およびいくつかのパス感度の高いチェックがテイント情報を消費して追加の警告（ゼロ除算チェッカーなど）を発するように教えられており、テイント「シンク」として機能し、チェッカー固有の「サニタイズ」条件を定義します。 この機能全体は実験的としてフラグが立てられています。基本的には概念実証の実装です。実際によく機能するようにできる可能性は高いですが、実際のソースコードで実行することによる品質管理が必要であり、特に個々のチェックにおいて、安定版として宣言する前に多数のバグに対処する必要があります。さらに、最も興味深いチェックである、汚染されたループ境界またはサイズパラメーターに基づくバッファオーバーフロー検出は、まだ実装されていません。また、汚染されたインデックスによる配列アクセスに関する関連チェックもあります。これもまた実験的なものです。これも安定版として宣言できるかどうか見てみましょう！ 期待される結果: 静的アナライザーのすべてのユーザーに対してデフォルトで有効になっているか、セキュリティに関心のあるユーザーがオプトインで利用できる、いくつかのテイント関連のチェック。それらは、実際のコードで低い誤検出率であることが確認されています。うまくいけば、バッファオーバーフローチェックもその一つとなるでしょう。 望ましいスキル: LLVMコードを理解するための、中級レベルのC++スキル。いくつかのプレーンCコードでも分析を実行します。コンパイラーまたはセキュリティの背景知識は歓迎されますが、必須ではありません。 プロジェクトサイズ：中または大。 難易度：中 確定済みのメンター: Artem Dergachev、Gábor Horváth、Ziqing Luo ディスカッション: URL プロジェクトの説明 これは、GSoC 2020および2021の作業を継続するものです。開発者は通常、-O2や-O3のような標準的な最適化パイプラインを使用してコードを最適化します。どの最適化パスを選択し、それらのパスの実行順序を決定するために、手動で作成されたヒューリスティクスが使用されます。しかし、このプロセスは、あらゆる入力に対して「それなりにうまく」機能するように設計されているため、特定のプログラムやプログラムの種類に合わせて調整されていません。既存のヒューリスティクスを改善するか、機械学習ベースのモデルでヒューリスティクスを置き換えて、LLVMコンパイラーがプログラムごとにカスタマイズされた最適なパス順序を提供できるようにしたいと考えています。最後のマイルストーンでは、特徴抽出を有効にし、より適切なパスパイプラインを選択するためのポリシーのトレーニングを開始しました。 プロジェクト規模: 175時間または350時間のいずれか。 難易度：中 スキル: C/C++、コンパイラーに関するいくつかの経験。MLの経験があれば尚可。 期待される成果: パフォーマンスの低下なしに、最も経済的な最適化パイプラインを選択する事前トレーニング済みモデル、LLVMでのモデルの組み込み、（再）トレーニングツール、検索または学習による新しい最適化シーケンスの考案。 メンター Tarindu Jayatilaka, Mircea Trofin, Johannes Doerfert ディスカッション URL プロジェクトの説明 期待される結果: 生成されたカバレッジHTMLレポートに階層的なディレクトリ構造のサポートを実装し、この機能のLLVMリポジトリコードカバレッジレポートでの使用状況を示します。 プロジェクト規模: 中規模または大規模 難易度：中 確定済みのメンター: Gulfem Savrun Yeniceri Petr Hosek ディスカッション: URL プロジェクトの説明 開発者は、コードを最適化するために、コンパイラーが生成した注釈や分析レポートをよく使用します。一般にコンパイラーは、生成されたメッセージにソースコードの位置（つまり、行番号と列番号）を含めるのが得意ですが、これらの生成されたメッセージに対応するソースレベルの式も含まれていると便利です。LLVMの実装で使用されるアプローチは、LLVMプログラムオブジェクトとソースレベルの式間のマッピングを定義するために、小さな一連の組み込み関数を使用することです。このプロジェクトの目標は、これらの組み込み関数に含まれる情報を使用して、LLVMの値に対応するソース式を生成するか、既存の情報が不十分な場合に同じ情報を取得するためのソリューションを提案および実装することです。プログラムのメモリアクセスを最適化することは、アプリケーションのパフォーマンスにとって重要です。特に、コンパイラーの最適化を阻害するLLVMロード/ストア命令に対応する、ソースレベルのメモリアクセスを報告するコンパイラー分析メッセージを使用する予定です。例として、この情報を使用して、ベクトル化を阻害するメモリアクセスの依存関係を報告できます。 プロジェクト規模: 中規模 難易度：中 スキル: 中級レベルのC++、LLVMコアに関する知識、またはそれらを学ぶ意欲。 期待される結果: LLVMの値を受け取り、同等のソースレベルの式に対応する文字列を返すインターフェースを提供します。特に、このインターフェースを使用して、ロード/ストア命令で使用されるアドレスを同等のソースレベルのメモリ参照にマップすることに関心があります。 確定済みのメンター: Satish Guggilla (satish.guggilla@intel.com) Karthik Senthil (karthik.senthil@intel.com) ディスカッション: URL プロジェクトの説明 スキル: 中級レベルのC++プログラミングスキル、コンパイラー、LLVM IR、MLIR、またはClangに関する知識があれば尚可ですが、学ぶ意欲があればそれも可能です。 期待される結果:llvm-test-suiteのSingleSourceサブディレクトリからプログラムを構築および実行し、結果（パフォーマンスとビルド時間）を通常の（アップストリーム）clangコード生成と比較して収集し、提示します。 プロジェクト規模: 大規模 難易度：中 確定済みのメンター: Bruno Cardoso Lopes Nathan Lanza ディスカッション: URL プロジェクトの説明: Enzymeは、LLVMプログラムの自動微分（微積分の意味で）を実行します。これにより、ユーザーはEnzymeを使用して、MLでのバックプロパゲーションや、LLVMに変換される任意の言語の既存のコードでの科学的シミュレーションなどのさまざまなアルゴリズムを実行できます。ますます多くのLLVMバージョン（7〜メイン）、ADモード（反転、順伝播、順伝播ベクトル、反転ベクトル、ヤコビアン）、およびライブラリ（BLAS、OpenMP、MPI、CUDA、ROCmなど）のサポートにより、コードベースは着実に増加しています。複雑さを制限し、新しい貢献者を支援するために、LLVM Tablegenを使用してコアロジックのより多くの部分を表現したいと考えています。応募者は、Enzyme内のプログラム変換抽象化をTablegenに最適にマッピングする方法を自由に決定できます。 期待される結果: 1. Enzyme内のtablegenルール生成システムを拡張して、AdjointGeneratorの他に新しいコンポーネントをカバーする。 確定済みのメンター: Manuel Drehwald William Moses 望ましいスキル: C++、微積分、およびLLVMおよび/またはClang、および/またはMLIRの内部構造に関する十分な知識。Tablegen、Enzyme、または自動微分の経験があると良いですが、プロジェクトで学ぶこともできます。 プロジェクト規模: 大規模 難易度：中 ディスカッション URL プロジェクト概要 LLVMにおける日々のテストのほとんどは、Litによって実行される回帰テストであり、テスト対象のコードを直接呼び出すのではなく、ソースコードやIRとしてバイナリに渡されます。これには多くの利点がありますが、特にエラー処理が絡むようなエッジケースでは、特定のテスト入力でコンパイラが起動されたときにどのコードパスが実行されるかを予測するのが難しい場合があります。このプロジェクトの目標は、開発者がパッチに対して十分なテストカバレッジを作成するのを支援し、レビュー担当者がそれを検証できるようにすることです。これを実現するために、パッチを入力として受け取り、影響を受けるソースファイルのカバレッジ計測を追加し、Litテストを実行し、どのテストケースが各カウンタを実行したかを記録するツールを導入したいと考えています。各カウンタについて、カウンタを実行するテストケースの数を報告することができますが、おそらくもっと重要なのは、パッチによって何らかの形で変更されたテストケースでカウンタを実行するテストケースの数も報告できるということです。変更された行が同じテスト結果をもたらす場合、それが非機能的な変更を意図したものでない限り、適切にテストされていないからです。これは3つの独立した部分で実装できます。
プロジェクト規模: 小規模または中規模 難易度: 簡単 スキル: Lit、データ処理、およびdiff処理のためのPython。コンパイラの経験は必要ありません。 期待される結果: コミュニティで使用するための新しいツールを実装します。開発者は開発中にカバーされていないエッジケースを見つけるのに役立ち、コードが実際に実行されていることを確認するためだけにアサートやログを気まぐれに散りばめることを避けることができます。レビュー担当者は、各テストによってパッチのどの部分がテストされているかをより簡単に確認できます。 確定済みのメンター: Henrik Olsson ディスカッション: URL Google Summer of Code 2022は、LLVMプロジェクトにとって非常に成功したものでした。承認されたプロジェクトと完了したプロジェクトのリストについては、Google Summer of CodeのWebサイトをご覧ください。 プロジェクト概要: 共有メモリベースのJITLinkMemoryManagerを作成します。 期待される結果
確認済みのメンター: Vassil Vassilev、Lang Hames 望ましいスキル: 中級レベルのC++; LLVM、特にLLVM JITの理解; 仮想メモリ管理APIの理解。 プロジェクトタイプ: 大規模 ディスカッション URL プロジェクト概要: LLVMのBuildingAJITチュートリアルシリーズは、読者にLLVMのORC APIを使用して独自のJITクラスをゼロから構築する方法を教えますが、チュートリアルの章は最近のAPIの改善に追いついていません。既存のチュートリアルの章を最新の状態にし、レイジーコンパイルに関する新しい章を作成（章のコードは既に利用可能）するか、新しい章をゼロから作成します。 期待される結果
確認済みのメンター: Vassil Vassilev、Lang Hames 望ましいスキル: 中級レベルのC++; LLVM、特にLLVM JITの理解; RST（reStructured Text）の知識; 技術的なライティングスキル。 プロジェクトタイプ: 中規模 ディスカッション URL プロジェクト概要: JITLinkはLLVMの新しいJITリンカーAPIです。コンパイラの出力（リロケータブルオブジェクトファイル）をメモリ内の実行可能なバイトに変換する低レベルAPIです。これを行うために、JITLinkの一般的なリンカーアルゴリズムは、ターゲットオブジェクト形式（COFF、ELF、MachO）とアーキテクチャ（arm、arm64、i386、x86-64）をサポートするように特殊化する必要があります。LLVMには、MachO/arm64およびMachO/x86-64用のJITLinkの成熟した実装と、ELF/x86-64用の比較的新しい実装が既にあります。興味のある不足しているターゲット用のJITLink実装を作成します。ELFまたはMachO形式を使用して新しいアーキテクチャのサポートを実装することを選択した場合、これらの形式の既存の汎用コードを再利用できます。COFF形式を使用して新しいターゲットのサポートを実装する場合は、選択したアーキテクチャの汎用COFFサポートコードとアーキテクチャサポートコードの両方を記述する必要があります。 期待される結果: まだサポートされていない形式/アーキテクチャのJITLink特殊化を作成します。 確定済みのメンター: Vassil Vassilev、Stefan Gränitz、Lang Hames 望ましいスキル: 中級のC++; LLVM、特にLLVM JITの理解; 選択した形式/アーキテクチャに関する知識、および基本的なリンカーの概念 (セクション、シンボル、再配置など)。 プロジェクトタイプ: 大規模 ディスカッション URL プロジェクト概要: すべての開発者は、いつか（通常はプログラムのコンパイルを待っている間）「なぜこんなに時間がかかるのか？」と疑問に思ったことがあるでしょう。このプロジェクトは、この質問に対する答えを探すものです。LLVM、そして拡張してCLANG内には、コンパイラ内のイベントを記録するタイミングインフラストラクチャが存在します。ただし、その利用は一貫性がなく、不十分です。これは、LLVMとCLANG全体にさらに多くの計測を追加することで改善できますが、注意が必要です。計測が多すぎたり、間違ったものを計測したりすると、混乱し、圧倒される可能性があるため、情報が不足している場合とそれほど違いはありません。重要なのは、計測する適切な場所を見つけて、計測を制御することです。これらの重要なスポットを探すことで、プリプロセスから最終的なコード生成まで、コンパイルプロセス全体を理解することができます。コードを計測するときは、進化に応じてデータを確認し、それが検索をさらに導きます。コンパイラが時間を費やしている場所をよりよく理解できるように、情報を制御およびフィルタリングする新しい方法を開発します。コンパイラを改善できる場所を示すサンプルテスト入力を探し出し、開発します。これにより、計測と検索がさらに導かれます。コンパイルの段階をよりよく理解し、詳細に検討できるように、計測を制御する方法を検討および開発します。このすべてを通して、コンパイラがどのように機能するかを、フロントエンド処理からLLVM最適化パイプライン、コード生成まで理解することができます。C/C++プログラムをコンパイルおよび最適化するために必要なことの全体像、特にCLANG、LLVM、およびLLCがこれらのタスクをどのように実行するかを確認し、理解することができます。あなたのメンターは、コンパイラ開発で約25年、LLVM自体で約8年の経験を合わせて持ち、あなたの探求をサポートします。 期待される結果
確定済みのメンター: Jamie Schmeiser、Whitney Tsang 望ましいスキル: C++プログラミングスキル; CLANG/LLVMの知識は資産ですが、必須ではありません。自発的な動機付け; 好奇心; 学習意欲 プロジェクトタイプ: 175時間または350時間 難易度: 簡単 - 中 ディスカッション URL プロジェクト概要 これは、GSoC 2020と2021の作業を継続するものです。開発者は通常、-O2や-O3などの標準最適化パイプラインを使用してコードを最適化します。手動で作成されたヒューリスティックを使用して、どの最適化パスを選択するか、およびそれらのパスの実行順序を決定します。ただし、このプロセスは、あらゆる入力に対して「妥当なパフォーマンス」を発揮するように設計されているため、特定のアプリケーションやアプリケーションの種類に合わせて調整されていません。既存のヒューリスティックを改善するか、ヒューリスティックを機械学習ベースのモデルに置き換えて、LLVMコンパイラがアプリケーションごとにカスタマイズされた優れたパス順序を提供できるようにしたいと考えています。最後のマイルストーンでは、特徴抽出が可能になり、より適切なパスパイプラインを選択するためのポリシーのトレーニングの調査を開始しました。 プロジェクト規模: 175時間または350時間のいずれか。 難易度：中 スキル: C/C++、コンパイラーに関するいくつかの経験。MLの経験があれば尚可。 期待される成果: パフォーマンスを損なうことなく、最も経済的な最適化パイプラインを選択する事前トレーニング済みのモデル; LLVMへのモデルのフックアップ; （再）トレーニングツール。 メンター Tarindu Jayatilaka, Mircea Trofin, Johannes Doerfert ディスカッション URL プロジェクト概要 このプロジェクトは、昨年の継続です。2021年、プロジェクトは最初のマイルストーンである、正確さの決定をポリシーの決定から分離することを達成しました。これにより、後者を機械学習されたものに置き換える可能性が開かれます。おおよそのマイルストーン：1）特徴の初期セットを選択し、既存のML Guided Optimizations（MLGO）インフラストラクチャを使用してトレーニングログを生成します。2）強化学習トレーニングループをガイドするために、コンパイル時に計算可能な報酬シグナルを定義します。3）トレーニングを繰り返し、報酬/特徴セットを調整します。 プロジェクト規模: 175時間または350時間のいずれか、理想的には350時間 難易度: 中程度/難しい スキル: C/C++、コンパイラーに関するいくつかの経験。MLの経験があれば尚可。 期待される成果: ループアンローリングのポリシー（「アドバイザー」）インターフェース。現在のヒューリスティックがデフォルトの実装です。強化学習トレーニングのための特徴抽出を設定します。報酬メトリックを設定します。トレーニングアルゴリズムを設定し、ポリシーのトレーニングを繰り返します。 メンター Johannes Doerfert、Mircea Trofin ディスカッション URL プロジェクトの説明 LLVMのインライナーは、ボトムアップの強連結成分レベルのパスです。これにより、呼び出しサイトが評価される順序に制限が課せられ、インライン化の有効性に影響を与えます。現在、GSoC2021の成果として、機能的なモジュールインライナーが存在します。今後、呼び出しサイトの優先度スキーム、インライン化成功後の関数パス実行の有効性/頻度、MLインラインアドバイザーとの相互作用など、いくつかの領域を探求したいと考えています。 プロジェクト規模: 175時間または350時間。理想は350時間ですが、マイルストーンにより175時間にスコープすることも可能です。 難易度: 中程度/難しい スキル: C/C++、コンパイラの経験が多少あること。 期待される成果: 代替トラバーサル順序の提案と評価。インライン化決定の「クラスタリング」（一度に複数の呼び出しサイトをインライン化）の評価。インライン化後の関数最適化パスの有効性/頻度の評価。 メンター 平田 和、陶 力強 (Liqiang Tao)、ミルチャ・トロフィン (Mircea Trofin) ディスカッション URL プロジェクトの説明: CおよびC++プログラムは、個別にコンパイルされたソースファイルから生成されたさまざまなオブジェクトファイルで構成され、それらがリンクされて結合されることがよくあります。1つのソースファイルをコンパイルする場合、他のソースファイル内のロジックから得られる知識は通常利用できません。リンク時最適化（LTO）は、複数のソースファイルからの情報を使用して最適化を行う方法です。 LLVMでは、LTOは、「コンパイル」ステップからの出力としてLLVMビットコードオブジェクトを使用し、それらのオブジェクトをリンクステップに供給することによって実現されます。LLVMのLTOは、リンカーと連携して動作します。リンカーはユーザーによって呼び出され、LLVMビットコードファイルが検出されると、リンカーはLLVMのLTOを駆動し、ビットコードオブジェクトが定義または参照するシンボルに関する情報をLTOから取得します。オブジェクトで定義または参照されているシンボルに関する情報は、リンカーがシンボル解決を実行するために必要であり、リンカーは通常、そのような情報を通常の（非ビットコード）オブジェクトファイルから抽出できます。 特に、オブジェクトとセクションを遅延インクルードする積極的な形式のリンカーGC（リンカーガベージコレクション）に関して、LLVMのLTO実装がリンカーGCに及ぼす影響は改善の余地があります。具体的には、LTOモジュールによって参照されるが未定義のシンボルは、リンカーにとってはモジュールレベルでモノリシックです。同時に、通常の（非LTO）オブジェクトによって参照されるが未定義のシンボルは、LTOに対してモノリシックです。まとめて考えると、LTOモジュールをプロセス全体に含めることは、リンカーの初期シンボル解決において、そのモジュール内のすべての未定義シンボルが参照されていると見なされる可能性があり、結果として、追加の成果物（例えば、アーカイブメンバー）が解決に追加される可能性があり、これにより、LTOモジュールで定義されたシンボルに解決される参照が生じ、これらのシンボルの定義が必要であるという早期の結論につながります。これは少なくとも、最終的にガベージコレクションされる関数に対して不必要なコード生成が行われている可能性があることを意味します（電気と時間の無駄）。 理想的な実装には、リンカーとLTOコード生成の間で情報が行き来する「コルーチン」のような対話が必要になる可能性があることは認識していますが、そのような取り組みはリンカーとLLVMの両方にとって侵襲的です。 私たちは以下の方法により、
LTO処理は、LTOユニットの外部に可視であるLTOシンボルのより正確なセットを効果的に識別できるようになると考えています。リンカーは、エクスポートされたシンボルとエントリポイント（実行可能ファイルのエントリポイントや、初期化と終了に関与する関数など）のみを識別する必要があります。 LLVMのopt/codegenに「外部世界」からの依存関係の影響を理解させることは、他の方向よりも明らかに優れています。非LTOコード内の再配置によって参照されるシンボルは、コンパイルされた時点でほぼ固定されている（一方で、LTOコード内の参照の一部は最適化で消滅する可能性がある）からです。 期待される結果
確認済みメンター: ショーン・ファータイル (Sean Fertile), ヒューバート・トン (Hubert Tong), ワエル・イェヒア (Wael Yehia) 望ましいスキル: 中級レベルのC++; 基本的なリンカーの概念（シンボル、セクション、再配置など） プロジェクト規模: 350時間 難易度: 中/高 ディスカッション URL プロジェクトの説明 LLVMにundef値が存在すると、プログラムでundef値が使用されていない場合でも、いくつかの最適化が妨げられます。したがって、最終的にLLVMからundefを削除できるように、undefのすべての使用箇所をpoisonに移行しようとしています。 プロジェクト規模: 350時間 難易度: 中程度/難しい スキル: 中級レベルのC++ 期待される成果:
メンター: ヌーノ・ロペス (Nuno Lopes) プロジェクトの説明 現在、LLVM内のすべてのライブラリは、すべてのシンボルを公開的にエクスポートしています。それらに対して静的にリンクする場合、リンカーは未使用のシンボルを削除するため、これは問題ではありません。 ただし、ライブラリが共有ライブラリとしてビルドされる場合、エクスポートされるシンボルの数が非常に多く、内部向けであるはずのシンボルが共有libLLVM.soの公開ABIに漏れてしまいます。 このプロジェクトでは、ライブラリシンボルのデフォルトの可視性を「隠し」に変更し、LLVMにアノテーションマクロを追加し、そのマクロを使用してライブラリ全体を徐々にこの方向に移行したいと考えています。これにより、最終的にWindowsでも共有libLLVM.soをビルドできるようになります。
実際には、これは個々のライブラリに-fvisibility=hiddenを追加し、エクスポートされたシンボルにLLVMエクスポートアノテーションを付けることを意味します。 この作業が他の開発者のワークフローになるべく侵入しないようにしたいので、小さな内部ライブラリ、たとえば、LLVMターゲットまたはIRパスのいずれかから始めるのが有益です。 詳細については、この提案の背後にあるアイデアについて議論しているDiscourseスレッドがあります: WindowsでLLVM_BUILD_LLVM_DYLIBをサポートする。また、機能を実装するパッチを含むリンクされたPhabricatorレビューもあります: ⚙ D109192 [WIP/DNM] サポート: パブリックAPIアノテーションサポートを導入。この作業はまだコミットされていませんが、この提案の出発点として使用できます。 プロジェクト規模: 中規模 難易度: 簡単 スキル: ビルドシステム、CMake、LLVM 期待される成果:
メンター: ティム・ベーダー (Timm Bäder)、トム・ステラード (Tom Stellard) プロジェクトの説明: テンプレートをインスタンス化するとき、テンプレート引数は、テンプレートパターンに置き換えられる前に正規化されます。Clangは、インスタンス化のメンバーに後でアクセスするときに、型糖衣構文を保持しません。 std::vector<std::string> vs;
int n = vs.front(); // bad diagnostic: [...] aka 'std::basic_string<char>' [...]
template<typename T> struct Id { typedef T type; };
Id<size_t>::type // just 'unsigned long', 'size_t' sugar has been lost
Clangは、アクセスされた特殊化の型糖衣構文に基づいて、クラステンプレート特殊化でメンバーアクセスを実行するときに型を「再糖衣」する必要があります。vs.front() の型は std::basic_string<char, [...]> ではなく、std::string である必要があります。提案された設計アプローチ: テンプレート引数の糖衣構文を表す新しい型ノードを追加し、クラステンプレート特殊化のメンバーがアクセスされるたびに、このノードのインスタンスを暗黙的に作成します。このノードの単一ステップの脱糖衣を実行するとき、糖衣構文のテンプレート引数を内部型ノードに伝播することによって、脱糖衣構文された表現を遅延作成します（特に、Subst*Parmノードを対応する糖衣構文に置き換えます）。診断のために型を出力するときは、注釈付きの型糖衣構文を使用して、元々記述された型を出力します。 良い結果を得るには、テンプレート引数の推論も型糖衣構文を推論できる必要があり（同じ型が異なる糖衣構文で2回推論される場合を調整する必要がある）、型糖衣構文を推論できる必要もあります。 期待される結果: テンプレート特殊化のメンバーにアクセスするときでも、診断は型糖衣構文を保持します。T<unsigned long>とT<size_t>は依然として同じ型であり、同じテンプレートインスタンス化ですが、T<unsigned long>::typeは単一ステップで脱糖衣構文されて'unsigned long'になり、T<size_t>::typeは単一ステップで脱糖衣構文されて'size_t'になります。 確認済みメンター: ヴァシル・ヴァシレフ (Vassil Vassilev)、リチャード・スミス (Richard Smith) 望ましいスキル: clang API、clangのASTに関する優れた知識、C++に関する中級レベルの知識。 プロジェクトタイプ: 大規模 ディスカッション URL プロジェクトの説明： 静的アナライザーは、clang ASTが内部で処理を行うことで、多くの新しいC++の機能が自動的にサポートされますが、C++17の「構造化束縛」構文 auto [x, y] = ...;は、静的アナライザー側で追加の作業が必要です。アナライザーの転送関数は、新しいASTノードであるBindingDeclとDecompositionDeclについて、標準で記述されている3つの解釈すべてで正しく機能するように教える必要があります。 構造化束縛の不完全なサポートは、#42387のように、最近のC++コードで未初期化変数チェッカーにおける誤検出の一般的な原因となっています。 Clang CFGも更新する必要がある可能性があります。CFGのこのような変更は、静的アナライザーの外部でclangの警告の品質を向上させる可能性があります。 期待される結果： 静的アナライザーが構造化束縛と分解宣言を正しくモデル化すること。特に、束縛変数が静的アナライザーの未初期化変数チェッカーで未初期化と表示されないこと。 確定したメンター： Artem Dergachev, Rashmi Mudduluru, Gábor Horváth, Kristóf Umann 望ましいスキル： C++の中級レベルの知識。Clang ASTの知識または静的解析のバックグラウンド。 プロジェクト規模: 350時間 難易度: 中程度/難しい ディスカッション URL 説明：プログラマーに警告とエラーを発行するClang診断は、コンパイラーの重要な機能です。優れた診断は、コンパイラーのユーザーエクスペリエンスに大きな影響を与え、生産性を向上させることができます。 GCCの最近の改善 [1] [2] は、診断（および一般的なユーザーインタラクション）を改善するための大きな余地があることを示しています。このトピックに関するclangに対する可能なすべての改善点を調査および特定し、次世代の診断の再設計を開始することは、非常に影響力のあるプロジェクトとなるでしょう。 さらに、LLVM Github Issueページで clang-diagnosticsのラベルが付いた問題についても結論を出し、修正が必要な場合はパッチを準備し、それ以外の場合は単純に閉じます。 期待される成果： 診断が改善されます
確定したメンター： Aaron Ballman, Erich Keane, Shivam Gupta 望ましいスキル： C++のコーディング経験 プロジェクトタイプ： 大規模/350時間 ディスカッション URL プロジェクトの説明： 標準のPolly対応-O1/-O2/-O3最適化パスパイプラインは、新しいパスマネージャー（NPM）で正常に動作しますが、Pollyの一部はレガシーパスマネージャーでのみ動作します。これには、-polly-export-jscop/-polly-export-jscop、回帰テスト、Polly-ACC、-polly-showなどのコマンドラインオプション、-print-after-allなどで使用されるPassInstrumentationメカニズムなどのパスが含まれます。LLVM（およびClang）は、NPMをデフォルトとして使用するようになり、レガシーパスマネージャーのサポートは非推奨となり、徐々に劣化し、機能が削除されています。つまり、Pollyのすべての機能は最終的にNPMでも動作するようになり、レガシーパスマネージャーの完全な削除に備える必要があります。2つのパスマネージャーの詳細については、こちらをご覧ください。 期待される結果： 目標は、NPMのみを使用してPollyをより使いやすくすることです。マイルストーンは、このGSoCで必ずしもすべてに到達する必要はありません。 確定したメンター： Michael Kruse 望ましいスキル： 新しいパスマネージャーで使用されるC++テンプレートパターン（CRTP、Mixinなど）の理解。LLVMがリンク（静的、BUILD_SHARED_LIBS、およびSHLIB/DYLIB）される方法と、そのプラグインロードメカニズム（静的、-load、および-load-pass-plugin）に関する知識。理想的には、すでにLLVMの新しいパスマネージャーで作業した経験があること。 プロジェクト規模: 中規模 難易度: 中程度/難しい ディスカッション URL プロジェクトの説明： Enzymeは、LLVMプログラムの（微積分の意味での）自動微分を実行します。これにより、ユーザーはEnzymeを使用して、MLでのバックプロパゲーションやLLVMに低レベル化する任意の言語の既存のコードでの科学シミュレーションなど、さまざまなアルゴリズムを実行できます。増加するLLVMバージョン（7-main）、ADモード（逆、順、順ベクトル、逆ベクトル、ヤコビアン）、およびライブラリ（BLAS、OpenMP、MPI、CUDA、ROCm、...）のサポートにより、コードベースは着実に増加しています。複雑さを制限し、新しい貢献者を支援するために、コアロジックをLLVM Tablegenを使用して表現したいと思います。応募者は、Enzyme内のプログラム変換抽象化をTablegenに最適な方法でマップする方法を自由に決定できます。 期待される結果： 1. Enzyme内の動作するtablegenルール生成システム 確定したメンター： William Moses, Valentin Churavy 望ましいスキル: C++、微積分、およびLLVMおよび/またはClang、および/またはMLIRの内部構造に関する十分な知識。Tablegen、Enzyme、または自動微分の経験があると良いですが、プロジェクトで学ぶこともできます。 プロジェクト規模: 大規模 難易度：中 ディスカッション URL プロジェクトの説明： Enzymeは、LLVMプログラムの（微積分の意味での）自動微分を実行します。これにより、ユーザーはEnzymeを使用して、MLでのバックプロパゲーションやLLVMに低レベル化する任意の言語の既存のコードでの科学シミュレーションなど、さまざまなアルゴリズムを実行できます。Enzymeはすでに順方向および逆方向モードの自動微分を実装しています。Enzymeはまた、ベクトル順方向モードの自動微分も実装しており、これにより、Enzymeは単一の呼び出しで複数のオブジェクトの導関数計算をバッチ処理できます。このプロジェクトの目標は、この機能を拡張してベクトル逆方向モードを実行することです。これにより、逆方向モードの自動微分の複数のスイープを同時に実行でき、メモリ、時間、およびその他の最適化をさらに有効にすることができます。 期待される結果： 逆モード自動微分のベクトル化バージョン 確定したメンター： William Moses, Tim Gymnich 望ましいスキル： C++の良好な知識とLLVM APIの経験。Enzymeまたは自動微分の経験があると良いですが、プロジェクトで学ぶこともできます。 プロジェクト規模: 中規模 難易度：中 ディスカッション URL プロジェクトの説明： Enzymeは、LLVMプログラムの（微積分の意味での）自動微分を実行するLLVMのコンパイラープラグインです。これにより、ユーザーはEnzymeを使用して、MLでのバックプロパゲーションやLLVMに低レベル化する任意の言語の既存のコードでの科学シミュレーションなど、さまざまなアルゴリズムを実行できます。 期待される結果： 1. Enzymeは新しいパスマネージャーによって呼び出すことができる 確定したメンター： William Moses, Valentin Churavy 望ましいスキル： C++とLLVMの良好な知識。Enzymeの経験があると良いですが、プロジェクトで学ぶこともできます。 プロジェクトサイズ： 小規模 難易度：中 ディスカッション URL Google Summer of Code 2021の学生の皆様、ようこそ！このドキュメントは、LLVM、Clang、およびその他の関連サブプロジェクトの興味深く重要なプロジェクトを見つけるための出発点です。このプロジェクトリストは、Google Summer of Codeのためだけに開発されたものではなく、開発者が取り組む必要があり、LLVMコミュニティにとって非常に有益なオープンプロジェクトでもあります。 このリストをよく見て、どのプロジェクトがあなたのスキルセットに合致し、ワクワクするかを確認することをお勧めします。また、このリストにない提案も歓迎します。LLVMコミュニティに開発者メーリングリスト（llvm-dev@lists.llvm.orgまたは特定のサブプロジェクトメーリングリスト）を通じてアイデアを提案する必要があります。コミュニティからのフィードバックは、提案が検討され、受け入れられるための要件です。 LLVMプロジェクトは、Google Summer of Codeに数年間参加しており、非常に成功したプロジェクトがいくつかあります。今年も例外ではなく、皆様からの提案をお待ちしております。提案の提出方法については、Google Summer of Codeのメインウェブサイトをご覧ください。 プロジェクトの説明： LLVM litテストスイートは、数千の小さな独立したテストで構成されています。テストの数が多いため、ハイスペックコンピューターでも、完全なスイートを実行するには長い時間がかかる場合があります。ビルドは、distccやicecreamなどのソフトウェアを使用して、同じネットワーク上で利用可能な複数のコンピューターに分散可能であるため、単一のマシンでテストを実行することが潜在的なボトルネックになります。テストの実行を高速化する方法の1つは、テストの実行を多くのコンピューターに分散することです。Litは、複数のコンピューターが同じテストスイートの一部を並行して実行できるようにするテストシャーディングメカニズムを提供しますが、これは現在、単一の共通ファイルシステムへのアクセスを前提としており、すべての場合に可能ではない可能性があり、スイートを現在実行できるマシンについての知識も必要です。このプロジェクトの目標は、既存のlitハーネスを更新（またはそのラッパーを作成）して、開発者がハーネスと選択した分散システム間の独自のインターフェイスを作成できるように、この方法でテストを分散できるようにすることです。このハーネスは、入力ファイルや実行可能ファイルなどのテストの依存関係を識別し、テストを（おそらくバッチで）分散システムに送信し、litがすでに実行しているのと同様の方法で、結果を受信、照合、ユーザーに報告できるようにする必要があります。 期待される結果： 上記のような使いやすいハーネス。分散システムを使用した場合、ユーザーがそのハーネスを使用するとテストスイートの実行が高速化されることが期待できるという証拠。 確定メンター: James Henderson 望ましいスキル: Python の十分な知識。LLVM lit テストの知識。分散システムに関する知識もあれば有益。 プロジェクトの説明: これは簡単な説明です。興味があれば、Johannes (IRC で jdoerfert) と Mircea Trofin にご連絡ください。インライン化の決定に ML フレームワークを導入することに成功しました。今度は、その範囲を拡大したいと考えています。このプロジェクトでは、アンロールファクターなどのループ変換ヒューリスティックに焦点を当てます。動機付けの例として、最適化が非常に不十分な短いトリップカウントのdgemmを見てみましょう。nounrollプラグマを使用すると、より良い結果が得られますが、gccにはまだ及びません。このプロジェクトはオープンエンドであり、さまざまなパス/ヒューリスティックを同時に検討することができます。 準備資料: LLVM コードベースの ML インライン化フレームワークと論文。LLVM 変換パス (ヒューリスティックに基づくもの)、例: ループアンロール。 期待される成果: 学習済み予測器による測定可能なパフォーマンスの向上、ML モデルから導出された「古典的」ヒューリスティックのセット。 確定メンター: Johannes Doerfert、Mircea Trofin 望ましいスキル: ML、C++、自己動機に関する中級レベルの知識。 プロジェクトの説明: これは簡単な説明です。興味があれば、Johannes (IRC で jdoerfert) にご連絡ください。ファジングは、多くのバグを明らかにします。 CSmith (その他) は、C のような言語でこれを行う方法を示しており、過去にはLLVM-IR ファジングを成功裏に使用しました。このプロジェクトでは、開発中の新しいパス (Attributor パスなど) にファジングを適用します。クラッシュだけでなく、コンパイル時のパフォーマンス問題を含む他のバグも見つけて修正したいと考えています。 準備資料: LLVM ファザーインフラストラクチャ。ファジングしたい LLVM パス (例: Attributor パス)。以前の IR ファジング作業 (https://www.youtube.com/watch?v=UBbQ_s6hNgg) 期待される成果: クラッシュ、おそらくパフォーマンスの問題を含むクラッシュ以外のバグを捕捉する方法。 確定メンター: Johannes Doerfert 望ましいスキル: C++ に関する中級レベルの知識、自己動機。 プロジェクトの説明: これは簡単な説明です。興味があれば、Johannes (IRC で jdoerfert) にご連絡ください。llvm.assume知識を保持するための強力なメカニズムです。その開始以来、すでに何度も改善されてきましたが、このプロジェクトで取り組みたい主要な拡張機能がまだ未解決のままです。トピックの不完全なリストには以下が含まれます
準備資料: llvm.assumption の使用法、アサンプションキャッシュ、"enable-knowledge-retention" オプション、RFC と このレビュー。 期待される成果: 新しい llvm.assume のユースケース、知識保持によるパフォーマンスの向上、アサーションに基づいた最適化。 確定メンター: Johannes Doerfert 望ましいスキル: C++ に関する中級レベルの知識、自己動機。 プロジェクトの説明: LLVM の IR には、根本的で長年の問題があります。その多くは未定義の動作に関連しています。その他は、単に仕様が不十分であることや、さまざまな人による異なる解釈によるものです。Alive2 は、LLVM の最適化におけるバグを自動的に検出するツールです。Alive2 を使用して、ダッシュボードの単体テストで発生するバグを追跡します。 期待される成果: 1) Alive2 によって検出されたバグを報告して修正します。2) 根本的な IR の問題を 1 つ選択し、セマンティクスの修正案を含め、その修正に向けて進捗させます。LLVM 単体テストと中規模プログラムで Alive2 を実行してセマンティクスの修正をテストし、セマンティクスの修正のパフォーマンスをテストし、パフォーマンスの回帰を修正します。 確定メンター: Nuno Lopes、Juneyoung Lee 望ましいスキル: 中級レベルの C++; LLVM IR セマンティクスについて学ぶ意欲。論文を読む経験 (推奨)。 プロジェクトの説明: LoopNest パスのアイデアは最近追加されたものであり、それを利用する既存のパスはありません。LoopNest パスを持つ前に、ループネストで動作するパスを記述する場合は、関数パスまたはループパスのいずれかを選択する必要がありました。関数パスとして記述することを選択した場合、パイプラインにループを動的に追加する機能が失われます。ループパスとして記述することにした場合、特定のループが一番外側のループでないときに、パスをトラバースしてすぐに戻るためにコンパイル時間を浪費することになります。このプロジェクトでは、最近導入された LoopNest パスをループネスト用に意図されたパスで使用し、LoopPass と同じようにパイプラインにループを動的に追加する機能を持ちたいと考えています。さらに、必要に応じて LoopNestPass の現在の実装を改善します。 期待される成果 (可能性): いくつかの既存の変換/分析に LoopNest パスを利用します。 確定メンター: Whitney Tsang、Ettore Tiotto 望ましいスキル: C++ に関する中級レベルの知識、自己動機。 プロジェクトの説明: これは簡単な説明です。興味があれば、Johannes (IRC で jdoerfert) にご連絡ください。OpenMP GPU カーネルは通常、ネイティブバイナリ (例: cubin) に低レベル化され、ホストオブジェクトに埋め込まれます。実行時、OpenMP 「プラグイン」は、デバイスドライバ (例: CUDA) と接続して、このような埋め込まれたバイナリイメージをロードして実行します。このプロジェクトでは、実行時にのみ既知のカーネルパラメータで IR を最適化し、他のプラグインで使用するために GPU バイナリを生成する新しいプラグインを開発したいと考えています。リモートオフロードプラグインと同様に、これをユーザーに透過的に行うことができます。プラグインに JIT インフラストラクチャをセットアップすることに加えて、IR をホストオブジェクトに埋め込む必要もあります。 準備資料:OpenMP ターゲットオフロードインフラストラクチャ、LLVM JIT インフラストラクチャ。 期待される成果: カーネルの特殊化によって最適化が可能になった場合に、優れたパフォーマンスを実現できる JIT 対応オフロードプラグイン。 確定メンター: Johannes Doerfert 望ましいスキル: C++、JIT コンパイルに関する中級レベルの知識、自己動機。 プロジェクトの説明: Clacc と Flacc は、Clang と Flang に OpenACC のサポートを導入するプロジェクトです。そのため、OpenMP ランタイム上に OpenACC ランタイムサポートが開発されています。ただし、LLVM の OpenMP ランタイムによって出力される診断は OpenMP の概念で表現されているため、これらの診断は常に OpenACC ユーザーにとって意味があるとは限りません。このプロジェクトでは、この問題を次の 2 つのステップで解決する必要があります
期待される成果: 必要に応じて OpenACC 診断を出力できる、アップストリームの LLVM の OpenMP ランタイムのバージョン。 確定メンター: Valentin Clement、Joel E. Denny 望ましいスキル: 中級レベルの C++。OpenACC または OpenMP の経験 プロジェクトの説明: Polly は、C で記述されたライブラリである整数集合ライブラリ (isl)のアルゴリズムを使用します。これは、メモリ管理に参照カウントを使用します。参照カウントを正しく行うことは、RAII を使用する C++ での方がはるかに簡単であるため、isl の C++ バインディングを作成しました: isl-noexceptions.h。それ以来、isl は 2 つの公式 C++ バインディング、cpp.h と cpp-checked.h も取得しました。Polly が維持している C++ バインディングをアップストリームバインディングに置き換えたいと考えています。残念ながら、これはインプレース置換ではありません。違いには、エラーのチェック方法、メソッド名、どの関数が演算子/コンストラクターのオーバーロードと見なされるか、およびエクスポートされた関数のセットが含まれます。これには、Polly による C++ バインディングの使用を変更し、Polly が必要とする追加機能をエクスポートするために isl にパッチを送信する必要があります。 期待される成果: Polly が維持している isl-noexceptions.h バインディングと、isl がサポートする 2 つの C++ バインディングのいずれかとの違いを減らします。isl-noexceptions.h がアップストリームバインディングよりも多くの関数とクラスをエクスポートしているため、完全な置き換えは恐らく範囲外になりますが、違いを減らすだけでも、Polly の isl-noexceptions.h のメンテナンスコストを削減できます。 確定メンター: Michael Kruse 望ましいスキル: C++ に関する深い知識 (特に RAII とムーブセマンティクス)。API 設計に関心があること。理想的には、すでにライブラリのヘッダーファイルをいくつか記述したことがあること。isl ライブラリの経験があればなお良いですが、プロジェクトで学ぶこともできます。 プロジェクトの説明: Enzyme は、LLVM プログラムの自動微分 (微積分の意味で) を実行します。これにより、ユーザーは Enzyme を使用して、ML でのバックプロパゲーションや、LLVM に低レベル化する既存のコードに関する科学シミュレーションなど、さまざまなアルゴリズムを実行できます。Enzyme は、微分される元の関数によって呼び出されるすべての関数内のすべての命令に連鎖ルールを適用することでこれを行います。機能的ですが、より高速な微分計算の代数特性を持つ可能性のある高レベルのマトリックス演算には必ずしも最適ではありません。Enzyme には、特定の関数にカスタム勾配を指定するメカニズムもあります。カスタム微分が利用可能な場合、Enzyme はそれを優先して使用し、独自の微分を実装するフォールバックを使用しません。多くのプログラムは、行列およびテンソル演算を効率的に計算するために BLAS ライブラリを使用します。このプロジェクトは、演算にカスタム微分ルールを指定することにより、BLAS や同様のライブラリ (Eigen など) の高性能な自動微分を可能にします。 期待される成果: 行列およびテンソル演算のカスタム微分ルールを記述することにより、BLAS および Eigen コードの効率的な微分。 確定メンター: William Moses、Johannes Doerfert 望ましいスキル: C++、微積分、線形代数の十分な知識。BLAS、Eigen、または Enzyme の経験があればなお良いですが、プロジェクトで学ぶこともできます。 プロジェクトの説明: Enzyme は、LLVMプログラムの（微積分的な意味での）自動微分を行います。これにより、ユーザーは Enzyme を使用して、MLのバックプロパゲーションや、LLVMに変換されるあらゆる言語の既存のコードに対する科学的シミュレーションなど、さまざまなアルゴリズムを実行できます。これは、LLVM IRを出力するあらゆるフロントエンドで機能しますが、追加情報を渡したり、より良いユーザーエクスペリエンスを作成したりするために、Enzymeとフロントエンド間のより緊密な統合が望ましい場合があります。Swiftは、フロントエンドでカスタム微分ルールを指定することで自動微分を提供します。EnzymeをSwiftに直接統合し、最終的なLLVMを微分することもできますが、カスタム微分に関するこの追加情報はすべて失われます。さらに、ナイーブに Enzyme を呼び出すことは、型チェックなし、きめ細かいAD固有のデバッグ情報なし、またはSwiftがADユーザーに提供するその他の便利なツールなしで行われます。このプロジェクトでは、EnzymeとSwiftフロントエンドを統合し、Enzymeを使用して高性能な自動微分を実現したいSwiftプログラマーに優れたユーザーエクスペリエンスを提供すると同時に、EnzymeがSwiftですでに利用可能な微分固有のメタデータを活用できるようにすることを目指します。 期待される結果: Enzymeを呼び出すためのSwiftでのカスタム型チェック付き言語構造の作成。Enzymeで使用するためのSwiftの微分固有のメタデータを渡すメカニズム。 メンター: William Moses, Vassil Vassilev 望ましいスキル: C++とSwiftに関する十分な知識。Enzymeまたは自動微分の経験があると良いですが、プロジェクトで学ぶこともできます。 プロジェクトの説明: Enzyme は、LLVMプログラムの（微積分的な意味での）自動微分を行います。これにより、ユーザーは Enzyme を使用して、MLのバックプロパゲーションや、LLVMに変換されるあらゆる言語の既存のコードに対する科学的シミュレーションなど、さまざまなアルゴリズムを実行できます。さまざまな分野で、浮動小数点値ではなく固定小数点値（例：整数）で計算することが望ましい場合があります。これにより、特定のアプリケーションにとって重大な可能性がある特定の切り捨てエラーを回避できます。さらに、特定のハードウェアでは、浮動小数点値よりも固定小数点値の方が効率的な場合があります。このプロジェクトでは、浮動小数点ベース値だけでなく、固定小数点ベース値の微分もサポートするように Enzyme を拡張することを目指します。 期待される結果: LLVM固定小数点イントリンシック、必要な型解析ルール、およびエンドツーエンドテストのためのフロントエンドへの統合のための随伴の実装。 メンター: William Moses 望ましいスキル: C++、微積分、およびLLVM内部に関する十分な知識。Enzymeまたは自動微分の経験があると良いですが、プロジェクトで学ぶこともできます。 プロジェクトの説明: Enzyme は、LLVMプログラムの（微積分的な意味での）自動微分を行います。これにより、ユーザーは Enzyme を使用して、MLのバックプロパゲーションや、LLVMに変換されるあらゆる言語の既存のコードに対する科学的シミュレーションなど、さまざまなアルゴリズムを実行できます。これは、LLVM IRを出力するあらゆるフロントエンドで機能しますが、追加情報を渡したり、より良いユーザーエクスペリエンスを作成したりするために、Enzymeとフロントエンド間のより緊密な統合が望ましい場合があります。このプロジェクトでは、EnzymeとRustフロントエンドを統合し、Enzymeを使用して高性能な自動微分を実現したいRustプログラマーに優れたユーザーエクスペリエンスを提供することを目指します。これには、LLVMプラグインのサポート/カスタムコードジェネレーションをrustcに統合することも含まれる可能性があります。 期待される結果: Enzymeを呼び出すためのRustでのカスタム型チェック付き言語構造の作成。Rustの型情報（LLVMデバッグ情報として表現）を直接型解析に解析するメカニズム。 メンター: William Moses 望ましいスキル: C++とRustに関する十分な知識。Enzymeまたは自動微分の経験があると良いですが、プロジェクトで学ぶこともできます。 プロジェクトの説明
メンター: Artem Dergachev プロジェクトの説明: CSAには小さな社内制約ソルバーがあり、かなり単純ですが非常に高速です。目標は、線形性を維持しながら、いくつかの記号演算子に対して範囲ベースのロジックをサポートすることです。さらに、制約ソルバーをテストするために特別に設計された単体テストフレームワーク（現在はかなりぎこちなくテストされています）を作成できます。このプロジェクトには、いくつかの興味深い特性があります。小さなチャンクに分割でき、各チャンクには自明でない解決策があります。ソルバーの世界を紹介できます（z3のような重量級のソルバーでアイデアを確認することをお勧めします）。既存のソルバーは単純であるため、試すことができる拡張機能は無数にあります。 メンター: Valeriy Savchenko プロジェクトの説明
Google Summer of Code 2020へのLLVMの参加は非常に成功し、多くの興味深いプロジェクトがLLVMに貢献しました。承認および完了したプロジェクトのリストについては、Google Summer of Code ウェブサイトをご覧ください。 プロジェクトの説明: これは簡単な説明です。興味がある場合は、Johannes（IRCのjdoerfert）に連絡してください。GSoC'19の間、LLVMのプロシージャ間機能を改善するためにAttributorフレームワークを構築しました。これはそれ自体で役立ちますが、特にインライン化が不可能または望ましくない状況で役立ちます。このGSoCプロジェクトでは、Attributorでまだ利用できない機能と、Attributorを既存のプロシージャ内およびプロシージャ間の最適化に接続する可能性について検討します。このプロジェクトでは、実際のタスクを決定する自由度が非常に高いですが、選択できる小規模および中規模のタスクのプールも提供します。 準備リソース: LLVM Developers Meeting 2019のAttributor YouTubeビデオと、同じ会議のIPOパネルの録画。LLVMのAttributorフレームワークとその他の既存のプロシージャ間解析および最適化。 期待される結果: 特にインライン化がオプションでない場合や望ましくない場合に、測定可能なIPOの改善。 確定メンター: Johannes Doerfert 望ましいスキル: C++の中級レベルの知識、自己動機。 プロジェクトの説明: これは簡単な説明です。興味がある場合は、Johannes（IRCのjdoerfert）に連絡してください。OpenMPOptパス（レビュー中）を使用すると、LLVM最適化パイプラインに、OpenMPランタイム呼び出しとしてエンコードされたOpenMP並列処理を教え始めました。このGSoCプロジェクトでは、OpenMPOptパスでまだ利用できない機能と、既存のプロシージャ内およびプロシージャ間の最適化、たとえばAttributorを接続する可能性について検討します。このプロジェクトでは、実際のタスクを決定する自由度が非常に高いですが、選択できる小規模および中規模のタスクのプールも提供します。 準備リソース: LLVM Developers Meeting 2018のYouTubeの「Optimizing Indirections, using abstractions without remorse」ビデオ。J. DoerfertとH. Finkelによる論文「Compiler Optimizations for OpenMP」および「Compiler Optimizations For Parallel Programs」（これらのスライドはさらに役立つ可能性があります）。 期待される結果: OpenMPに焦点を当てた並列プログラムの、測定可能なパフォーマンスまたはプログラム分析結果の改善。 確定メンター: Johannes Doerfert 望ましいスキル: C++の中級レベルの知識、自己動機。 プロジェクトの説明: デバッグ情報の生成は、コンパイラーが通常実行する基本的なタスクの1つです。生成された実行可能コードがデバッグ情報の存在に依存しないことは明らかです。 準備リソース
期待される結果
メンター: Paul Robinson and David Tellenbach 望ましいスキル: C++の中級レベルの知識、一般的なコンピューターアーキテクチャに関するある程度の知識、x86またはArm/AArch64命令セットに関するある程度の知識。 プロジェクトの説明: MergeSimilarFunctionsパスは、同一の関数だけでなく、命令にわずかな違いがある関数もマージして、コードサイズを削減できます。これは、マージされた関数に制御フローと追加の引数を挿入して、違いを説明することで行われます。この作業は2013年のLLVM Dev Meetingで発表されました。より詳細な説明は、LCTES 2014で論文として発表されました。コードはその時点でコミュニティにリリースされました。一方、このパスは過去数年間QuICで本番環境で使用されており、社内で積極的に保守されています。MergeSimilarFunctionsの影響を拡大するために、ThinLTOに移植され、パッチがアップストリームされました（以下に記載されている5つのパッチのスタックを参照）。しかし、LLVMアップストリームで既存のMergeFunctionsパスを置き換える代わりに、コミュニティはMergeSimilarFunctionsのアイデアで既存のパスを改善することを提案しました。そして、その上にThinLTOを活用します。ThinLTOで使用されるMergeSimilarFunctionは、幅広いワークロードで優れたコードサイズ削減を実現しており、この作業はLLVM-dev 2018で発表されました。ほとんどの組み込みシステム（スマートフォンなど）アプリケーションはコードサイズに制約があるため、LLVMプロジェクトはこのコードサイズ最適化から大きな恩恵を受けるでしょう。 準備リソース
期待される結果
確定済みのメンター: Aditya Kumar (IRCとphabricatorではhiraditya), JF Bastien (phabricatorではjfb) 望ましいスキル: コンパイラ設計の講義、SSA表現、C++の中級知識、LLVM Coreの知識。 プロジェクトの説明: LLVMはyaml2objというツールを提供しており、これはYAMLドキュメントをELF、COFF、Mach-Oといった様々なファイル形式のオブジェクトファイルに変換します。また、obj2yamlは逆の変換を行います。このツールは、LLVMの一部のテストで一般的に使用されます。YAMLは生のアセンブリよりもオブジェクトファイルの記述が容易であり、プリビルドされたバイナリよりも保守が容易なためです。DWARFは、LLVMで一般的に使用されるデバッグファイル形式です。LLVMのDWARF出力のテストの多くはアセンブリで記述されていますが、YAMLで記述する方が好ましいでしょう。しかし、yaml2objはDWARFセクションの出力を適切にサポートしていません。このプロジェクトは、yaml2objに、特にELFオブジェクトにおいてDWARFテストのテスト入力をより簡単に記述できるようにする機能を追加することを目的としています。 準備資料: DWARFファイル形式について、特にhttp://dwarfstd.org/Download.phpにある規格を読んでおくと役に立つでしょう。また、https://www.sco.com/developers/gabi/latest/contents.html に記述されているELFファイル形式の基礎を理解することも有益かもしれません。 期待される成果: オブジェクトファイルに対してDWARFセクションを生成するためにyaml2objを使用できるようになること。特に重要なことは、入力YAMLが同等のアセンブリよりも理解しやすいようにすることです。 確定済みのメンター: James Henderson 望ましいスキル: C++の中級知識。 プロジェクトの説明: LLVMにおけるHot Cold Splittingは、IRレベルの関数分割変換です。ホット/コールド分割の目標は、コードのメモリ局所性を改善し、起動時のワーキングセットを削減することです。分割パスは、コールドブロックを識別し、それらを別の関数に移動することでこれを行います。これはIRレベルで実装されているため、すべてのバックエンドターゲットがその恩恵を受けます。これは比較的新しい最適化であり、最近2019年のLLVM Dev Meetingで発表され、スライドはこちらにあります。ほとんどの利点は、__assert_rtnのような小さなブロックのアウトライン化から得られるため、このプロジェクトの目標は、静的解析（例：例外処理コード、最適化されたパーソナリティ関数）を介して潜在的なブロックを特定することです。コストモデルを使用して、アウトライン化が呼び出し元のコードサイズを削減することを確認し、命令を節約するために必要に応じて末尾呼び出しを使用します。 準備リソース
期待される結果
確定済みのメンター: Aditya Kumar (IRCとphabricatorではhiraditya) 望ましいスキル: コンパイラ設計の講義、SSA表現、C++の中級知識、LLVM Coreの知識。 プロジェクトの説明: 特定のアプリケーションに対して最適化パスを選択することは非常に重要ですが、コンパイラ変換スペース（パスの順序付けを含む）が膨大であるため、自明な問題ではありません。既存のヒューリスティクスは特定のアプリケーションに対して高性能なコードを提供できますが、幅広いアプリケーションコードに簡単に適用することはできません。このプロジェクトの目標は、LLVM変換パスとコード構造間の相互作用を学習し、既存のヒューリスティクスを改善（またはヒューリスティクスを機械学習ベースのモデルに置き換え）して、LLVMコンパイラがアプリケーションごとにカスタマイズされた優れたパス順序を提供できるようにすることです。 期待される成果（可能性）
準備リソース
確定済みのメンター: EJ Park, Giorgis Georgakoudis, Johannes Doerfert 望ましいスキル: C++、Python、LLVMの経験、および学習ベースの予測の経験が望ましい。 プロジェクトの説明: コンパイラ最適化のための現在の機械学習モデルは、分離された関数ごとの分析に基づいて関数に最適な最適化戦略を選択します。このアプローチでは、構築されたモデルは、各関数の最適な最適化戦略を決定するのに役立つ可能性のある、周囲の他の関数（呼び出し元または呼び出し先）との関係を認識していません。このプロジェクトでは、SCC（強連結成分）呼び出しグラフを探索して、関数ごとの最適な最適化戦略を見つけるための機械学習ベースのモデルを構築する際に、手続き間の機能を追加したいと考えています。さらに、関数ごとではなく、強く関連する関数をグループ化してグループとして最適化することが役立つ場合を調べたいと考えています。 期待される成果（可能性）
準備リソース
確定済みのメンター: EJ Park, Giorgis Georgakoudis, Johannes Doerfert 望ましいスキル: C++、Python、LLVMの経験、および学習ベースの予測の経験が望ましい。 プロジェクトの説明: PostDominatorTreeAnalysisの結果をループパスで使用する簡単な方法はありません。PostDominatorTreeAnalysisは関数分析であり、LoopStandardAnalysisResultsに含まれていないためです。LoopStandardAnalysisResultsにPostDominatorTreeAnalysisを追加すると、すべてのループパスでそれを保持する必要があり、つまり、すべてのループパスで結果が最新であることを確認する必要があります。このプロジェクトでは、ドミネータツリーのみを更新するのではなく、DomTreeUpdaterを使用してドミネータツリーとポストドミネータツリーを更新したり、MemorySSAを更新したりするために、さまざまなアップデーターで使用できる更新リストを生成するように、一般的に使用されるユーティリティをいくつか変更したいと考えています。さらに、既存のループパスをポストドミネータツリーを保持するように変更したいと考えています。最後に、LoopStandardAnalysisResultsにPostDominatorTreeを追加します。 期待される成果（可能性）: LoopStandardAnalysisResultsに追加されたPostDominatorTree。これにより、ループパスで使用できます。異なるアップデーターで簡単に取得できるように、より一般的なユーティリティが更新リストを生成するように変更されます。 確定済みのメンター: Whitney Tsang, Ettore Tiotto, Bardia Mahjour 望ましいスキル: C++ に関する中級レベルの知識、自己動機。 プロジェクトの説明: 現在、ループネストで動作するパスを記述する場合、関数パスまたはループパスのどちらかを選択する必要があります。関数パスとして記述することを選択した場合、パイプラインにループを動的に追加する機能が失われます。ループパスとして記述することを選択した場合、指定されたループが最も外側のループではない場合にパスをトラバースしてすぐに戻るため、コンパイル時間が無駄になります。このプロジェクトでは、ループネストを対象とした変換を継承できるLoopNestPassを作成し、ループをパイプラインに動的に追加するLoopPassと同じ機能を持たせたいと考えています。さらに、パスビルダーのさまざまなポイントでループネストパスを追加するために必要なすべてのアダプターを作成します。 期待される成果（可能性）: トランスフォーメーション/分析は、コンパイル時間やユーザビリティを損なうことなく、LoopNestPassとして記述できます。 確定メンター: Whitney Tsang、Ettore Tiotto 望ましいスキル: C++ に関する中級レベルの知識、自己動機。 プロジェクトの説明: TableGenは柔軟性があり、エンドユーザーがレコード（命令）の一般的なプロパティを定義および設定できます。すべてのターゲットには、数十または数百のそのような命令プロパティがあります。ターゲットコードが進化するにつれて、tdファイルはますます複雑になり、一部のプロパティの設定が必要かどうか、さらには正しいかどうかを確認することが難しくなります。例：hasSideEffectsプロパティがすべての命令に正しく設定されているかどうか。TableGenで生成されたファイルを調べて手動で検索するか、TableGenを実行するスクリプトを記述して特定のプロパティの出力を照合することができますが、命令プロパティを体系的にダンプおよびチェックできるスタンドアロンのユーティリティ（例：ターゲットがいくつかの検証ルールを定義できるようにするもの）は、ビルドプロセス管理の観点から優れている可能性があります。これにより、多くの隠れたバグを見つけて、全体的なコード生成コードの品質を向上させることができます。さらに、このユーティリティを使用して、命令プロパティの回帰テストを記述でき、LLVMの回帰テストの品質と精度を向上させることができます。 期待される成果（可能性）: 命令プロパティを体系的にダンプおよびチェックできるスタンドアロンのllvmツールまたはユーティリティ 確定済みのメンター: Hal Finkel, Jinsong Ji , Qingshan Zhang 望ましいスキル: C++ に関する中級レベルの知識、自己動機。 プロジェクトの説明: コードを移動することが安全かどうかを判断することは、LLVMのいくつかの変換（例：LICMのcanSinkOrHoistInst、またはLoopのmakeLoopInvariant）で実装されています。これらの各実装は、特定のクエリに対して異なる結果を返す可能性があり、コード移動の安全性チェックに矛盾が生じ、重複が発生します。一方、実際のコード移動を行うメカニズムも、変換ごとに異なります。コードの重複は保守上の問題を引き起こし、新しい変換を記述するのにかかる時間を増やします。このプロジェクトでは、まず、コードの移動が安全かどうかをチェックし、コードを移動するための、ループ変換（関数またはループパスである可能性があります）の既存のすべての方法を特定し、それを行うための標準化された方法を作成したいと考えています。 期待される成果（可能性）: コードの移動が安全かどうかをチェックし、コードを移動するための、既存のすべてのループ変換方法の標準化/スーパーセット 確定済みのメンター: Whitney Tsang, Ettore Tiotto, Bardia Mahjour 望ましいスキル: C++ に関する中級レベルの知識、自己動機。 プロジェクトの説明: Clang 静的解析器は、任意のコードにおけるヌルポインタ逆参照によるクラッシュを防ぐ方法をすでに知っていますが、コードが複雑すぎると「諦める」ことがよくあります。特に、スマートポインタやオプショナルなどの単純なものであっても、C++ 標準クラスの実装詳細は、解析器が完全に理解するには複雑すぎる場合があります。さらに、正確な動作は、どの標準ライブラリの実装（例えば、GNU libstdc++ や LLVM 独自の libc++）が使用されているかによって異なります。 C++ 標準クラスの動作について明示的に教えることで、解析器が C++ の最新コードでより多くのバグを見つけられるようにすることができます。これにより、解析器がすべての実装の詳細を独自に理解しようとするプロセス全体をスキップできます。例えば、デフォルト構築されたスマートポインタはヌルであり、それを逆参照しようとするとクラッシュが発生することを教えることができます。したがって、プロジェクトは、標準クラスのさまざまなメソッドの実装を手動で提供することで構成されます。 期待される結果: 静的解析器が、コード内でヌルスマートポインタの逆参照が発生する場合に警告を発するようにします。例えば、 #include <memory>
int foo(bool flag) {
std::unique_ptr<int> x; // note: Default constructor produces a null unique pointer;
if (flag) // note: Assuming 'flag' is false;
return 0; // note: Taking false branch
return *x; // warning: Dereferenced smart pointer 'x' is null.
}
少なくとも1つのクラスを完全にカバーできる必要があります。例えば、std::unique_ptrそして、結果を他のクラス（例えば、std::shared_ptrまたは C++17 のstd::optional.
など）に一般化できるかどうかを確認します。 望ましいスキル: C++の中級知識。 確定メンター: Artem Dergachev, Gábor Horváth プロジェクトの説明: LLDB のコマンドラインは、タブ補完やコマンド履歴など、UNIX シェルの機能に触発されたいくつかの便利な機能を提供しています。まだ実装されていない機能の1つに「オートサジェスト」があります。これは、ユーザーが入力したい可能性のあるコマンドの提案ですが、タブ補完とは異なり、ユーザーがコマンドを入力している間、カーソルのすぐ後ろに表示されます。これがどのように見えるかの良いデモンストレーションは、fish shellに実装されているオートサジェストです。 このプロジェクトは、LLDB の editline ベースのコマンドシェルにオートサジェストを実装することです。 望ましいスキル: C++の中級知識。 確定メンター: Jonas Devlieghere および Raphael Isemann プロジェクトの説明: LLDB のコマンドラインは、コマンドのタブ補完など、UNIX シェルの機能に触発されたいくつかの便利な機能を提供しています。これらのタブ補完は、LLDB のコマンドラインインターフェースだけでなく、IDE などの LLDB のグラフィカルインターフェースでも使用される補完エンジンによって実装されています。LLDB のタブ補完は非常に便利ですが、現在、すべてのコマンドとそれぞれの引数に対して実装されているわけではありません。このプロジェクトは、LLDB のコマンドの残りの補完を実装し、LLDB のユーザーエクスペリエンスを大幅に向上させることを目的としています。既存の補完の改善もプロジェクトの一部です。補完は文字列の静的なリストではなく、LLDB の内部状態を検査および理解する必要があることがよくあります。LLDB のコマンドとそのタブ補完は LLDB のすべての側面をカバーしているため、このプロジェクトは LLDB のすべての機能を概観するための良い方法を提供します。 望ましいスキル: C++の中級知識。 確定メンター:Raphael Isemann プロジェクトの説明: LLVM がコンパイラを構築するためのライブラリであるように、LLDB はデバッガを構築するためのライブラリです。LLDB は、安定した公開 SB API を提供します。歴史的な理由により、LLDB のコマンドラインインターフェースは現在、LLDB のプライベート API の上に実装されており、公開 API で既に実装されている多くの機能を複製しています。公開 API の上に LLDB のコマンドラインインターフェースを書き直すことで、実装が簡素化され、重複したコードが排除され、最も重要なこととして、テスト対象範囲が削減されます。 この作業は、時間の経過とともにオーバーロードが多すぎるコマンドの SB API をクリーンアップし、それらをオプションクラスを使用してすべてのバリアントを収集し、API を将来対応させる機会も提供します。 望ましいスキル: C++の中級知識。 確定メンター:Adrian Prantl および Jim Ingham プロジェクトの説明: テストスイートの緊張の1つは、プロセスを立ち上げてある時点まで到達させるのが安価な操作ではないため、そこに到達したら多くのテストを実行したいということです。しかし、現在のテストスイートは最初の失敗で中断するため、1つの失敗が他のすべてを失敗させるため、多くのテストを実行したくありません。一方で、アサーションの失敗によってテスト全体が失敗する必要がある個々のアサーションテストもあります。例えば、いくつかの変数値をチェックしたいブレークポイントで停止できなかった場合、テスト全体が失敗する必要があります。しかし、テストで5つの独立したローカル変数の値をチェックしたい場合、5つすべてを実行し、5つの変数アサーションのうちいくつが失敗したかを報告できるようにする必要があります。テストのバッチに対して開始マーカーと終了マーカーを追加し、テスト全体を失敗させることなくバッチ内のすべてのテストを実行し、必要に応じてエラーを報告してテスト全体を失敗させることで、これを実現できます。また、テストセクションにスコープオブジェクトを使用することで、Python でこれを行うのに良い方法があるかもしれません。 確定メンター: Jim Ingham 望ましいスキル: Python の中級程度の知識。 Google Summer of Code 2019 は LLVM プロジェクトに大きく貢献しました。受け入れられ完了したプロジェクトのリストについては、Google Summer of Code のWebサイトをご覧ください。 プロジェクトの説明: デバッグ情報（`clang -g` でコンパイル）を追加しても、生成されたコードはまったく変更されるべきではありません。残念ながら、バグがあります。これらは通常、修正がそれほど難しくなく、コードベースの新しい部分を発見するのに適した方法です！オブジェクトファイルを両方の方法でビルドし、テキストセクションを逆アセンブルすることをお勧めします。これにより、.s ファイルを比較するよりもクリーンな差分が得られます。 期待される結果: テストケースの削減、分析付きバグレポート（例えば、どのパスが原因か）、場合によってはパッチ。 確定メンター: Paul Robinson 望ましいスキル: C++ の中級程度の知識、x86 または ARM 命令セットのいくつかの知識。 プロジェクトの説明: Clang には ASTImporter が含まれており、これにより、Clang AST 間で宣言とステートメントを移動できます。これは、例えば、翻訳ユニット間の静的解析や LLDB の式評価器で使用されます。 現在の ASTImporter は、単純な C コードをある AST から別の AST に移動する場合、意図したとおりに動作します。ただし、C++ の OOP 機能やテンプレートなどの複雑な宣言は完全には実装されておらず、クラッシュや無効な AST ノードを引き起こす可能性があります。これらのクラッシュに関連するバグレポートは、LLDB の式評価器に対して提出されることが多く、最小限の再現ケースとともに提出されることはめったにありません。これにより、ASTImporter の改善は時間のかかる面倒な作業になります。 このプロジェクトは、これらの ASTImporter のバグを積極的に発見し、根本的なバグの理解と修正を容易にする最小限の再現ケースを提供するファザーを作成することを目的としています。
これは1つの可能なアプローチにすぎず、学生はファザーの動作方法について独自のアイデアを提出することを歓迎します。インポートされた AST のより多くの側面（例えば、AST ノードのソース位置、RecordDecls のサイズ）を自動的に検証できるアプローチを推奨します。ファザーとドライバーは C++ および/または Python で実装する必要があります。 望ましいスキル: C++の中級知識。 確定メンター: Raphael Isemann, Shafik Yaghmour プロジェクトの説明: Clang には、LLVM ブログに詳細が記載されている、新しく実装されたオートコンプリート機能があります。オートコンプリートにさらにフラグを追加し、より多くのシェル（現在は bash のみサポート）をサポートし、この機能を llvm-opt などの他のプロジェクトにエクスポートすることで、これを改善したいと考えています。受け入れられた学生は、Clang ドライバー、LLVM オプション、およびシェルスクリプトに取り組みます。 期待される結果: bash と zsh で動作するオートコンプリート、llvm-opt オプションのサポート。 確定メンター: Yuka Takahashi および Vassil Vassilev 望ましいスキル: C++ とシェルスクリプトの中級程度の知識 Google Summer of Code 2018 は LLVM プロジェクトに大きく貢献しました。受け入れられ完了したプロジェクトのリストについては、Google Summer of Code のWebサイトをご覧ください。 Google Summer of Code 2017 は LLVM プロジェクトに大きく貢献しました。受け入れられ完了したプロジェクトのリストについては、Google Summer of Code のWebサイトをご覧ください。 このドキュメントは、LLVM の「大きなTODOリスト」のようなものです。このドキュメントの各プロジェクトは、LLVM が持つと便利なものであり、システムに慣れるための優れた方法でもあります。これらのプロジェクトの中には、数日で実装できる小さく自己完結型のものもあれば、より大きなものもあります。これらのプロジェクトのいくつかは、それ自体で興味深い研究プロジェクトにつながる可能性があります。いずれにせよ、すべての貢献を歓迎します。 このページにあるプロジェクトは、オープンエンドです。より具体的なプロジェクトは、LLVMバグトラッカーに未割り当ての機能拡張として登録されています。LLVMの改善にご協力いただける場合は、現在未解決の問題リストをご覧ください。 メインのLLVMプロジェクトのハッキングに加えて、LLVMにはClangなどのいくつかのサブプロジェクトがあります。これらのプロジェクトに携わりたい場合は、それぞれの「オープンプロジェクト」ページをご覧ください。
現在のインフラストラクチャの改善は常に大歓迎であり、実装も比較的簡単です。以下は、改善が必要な主要な領域です... 現在、ClangとLLVMはどちらも別々のターゲット記述インフラストラクチャを持っており、一部の機能は重複し、他の機能は（Clangが特定の情報を問い合わせるために完全なLLVMターゲット記述を作成する必要があるという意味で）「共有」されています。 当初は両者が大きく異なり、異なる目的を果たしていたため、この分離は並行して進みました。しかし、コンパイラが進化するにつれて、コンパイラが適切に動作するように、両者間でますます多くの機能を共有する必要がありました。その例として、ターゲットがフラグを持たない特定の構成でデフォルト機能を備えている場合があります。バックエンドがフロントエンドとは異なる「デフォルト」の動作を持ち、後者が動作を強制する方法を持たない場合、機能しません。 別の方法としては、すべての小さな癖にフラグを作成することが考えられますが、第一に、LLVMの中間/バックエンドを使用しているのはClangだけではなく、第二に、それが「デフォルトの動作」が存在する理由であるため、要点を見失うことになります。 Clangドライバがアーキテクチャ、機能などを認識する方法（テーブル生成、ユーザー固有の構成ファイルなど）を修正するためのいくつかのアイデアが浮上していますが、どれも重要な問題である、バックエンドとの情報共有には触れていません。 最近、ClangとLLVMの両方からターゲット記述インフラストラクチャをファクタリングし、両方が使用する独自のライブラリにするというアイデアが浮上しています。これにより、すべてのデフォルト、フラグ、動作が確実に共有されるだけでなく、複雑さ（したがってメンテナンスコスト）も大幅に削減されます。また、すべてのツール（lli、llc、lld、lldbなど）が全体で同じ動作をすることにもなります。 主な課題は次のとおりです
LLVMバグトラッカーには、時々「コードクリーンアップ」バグが登録されています。これらのいずれかを取り上げて修正することは、LLVMコードに触れ、そのコンポーネントの一部がどのように機能するかを発見するための良い方法です。これらには、オプティマイザで多くのことを簡素化できるため、影響が大きい主要なIR再設計作業も含まれています。 特に実現したい具体的な例をいくつか示します
さらに、LLVMには修正が必要なパフォーマンスの改善があります。これらは次のキーワードでマークされています。slow-compileこのLLVMバグトラッカークエリを使用して検索してください。 llvm-testテストスイートは、生成されたコードのパフォーマンス、コンパイル時間、正確性などを夜間テストするために使用するプログラムの大規模なコレクションです。大規模なテストスイートを用意することで、プログラムの多くのカバレッジが提供され、コンパイラのあらゆる問題領域を特定して改善することができます。 コンパイラの詳細な知識を必要としない非常に役立つタスクの1つは、テストスイートを拡張して、新しいプログラムとベンチマークを含めることです。特に、ライブラリの依存関係が少なく、正確性テストに使用できる何らかの出力を生成し、ソース形式で再配布可能なCPU負荷の高いプログラムに関心があります。多くの異なるプログラムが適しています。たとえば、潜在的な候補の一部については、このリストをご覧ください。 LLVMで使用する新しいテストケースとベンチマークを常に探しています。特に、お気に入りのCソースコードをLLVMでコンパイルしてみると役立ちます。コンパイルできない場合は、その理由を特定するか、llvm-bugsリストに報告してください。プログラムをコンパイルできた場合は、ビルドシステムをLLVMプログラムテストスイートと互換性があるように変換すると非常に役立ちます。これにより、SVNにチェックインして、自動テスターがコンパイラの進捗状況を追跡するために使用できます。 コードをテストするときは、さまざまな最適化と、CBE、llc、lliのすべてのバックエンドを使用して実行してみてください。 テスト結果を使用するか、独自にベンチマークを見つけ、LLVMコードジェネレータが最適なコードを生成していない場合、または別のコンパイラがより良いコードを生成する場合。問題を実証するテストケースを最小化してみてください。次に、テストケースとLLVMが生成するコードと、生成されるはずのコードをバグとして送信するか、さらに良いのは、コードジェネレータを改善できるかどうかを確認してパッチを送信することです。基本的な考え方は、パフォーマンスの問題がわかっていれば修正するのが非常に簡単ですが、パフォーマンスが悪い理由を調べるリソースは通常ないということです。 LNTパフォーマンスデータベースには、移動平均、標準偏差、変動などを検出するなどの優れた機能があります。しかし、レポートページでは、個々の変動（ノイズが信号よりも大きくなる可能性がある）を強調しすぎています。たとえば、この例。 プロジェクトの最初の部分は、移動平均を追跡し、次のようにレポートする分析ツールを作成することです。
2番目の部分は、関連するすべてのベンチマーク（ダッシュボードのように構成可能）を表示し、ステータスを示す赤/黄/緑のカラーコードと、各ベンチマークの詳細な分析へのリンクを含む基本統計を表示するWebページを作成することです。 3番目の部分は、異なるビルドを自動的に相互参照できるようにすることです。これにより、アーキテクチャ/コンパイラ/CPU数でグループ化すると、この自動化ツールは変更が特定のグループでより一般的であることを理解します。 LLVMカバレッジレポートには、テストでカバーされているソース行を示すための優れたインターフェイスがありますが、どのテスト、どのリビジョン、どのアーキテクチャがカバーされているかは記載されていません。 LCOVを刷新するプロジェクトには、次のものが含まれます。
もう1つのアイデアは、テストスイートがホストアーキテクチャだけでなく、ビルドされたすべてのバックエンドを実行できるようにすることです。これにより、高速マシンでカバレッジレポートを作成でき、ビルドボットを更新する必要なく、コミットごとに1つのレポートを作成できます。
既存のものを改善するよりも、新しいものを作成する方が楽しい場合があります。これらのプロジェクトは、より複雑で、より多くの作業が必要になる可能性がありますが、非常にやりがいのあるものにもなります。 多くの提案されたLLVMコアの拡張と改善が、設計と実装を待っています。
ポインタ分析ベースの最適化とポインタ分析自体の両方の開発のための強力な基盤があります。これを活用したいと考えています。
オフラインコンパイル時でもJITでも動作する、プロファイルガイド変換を記述するための統合インフラストラクチャができました。しかし、変換自体は多くありません。新しいプロファイルガイド変換や、現在のプロファイリングシステムの改善を歓迎します。 プロファイルガイド変換のアイデア
既存のサポートの改善
LLVMはパフォーマンスを積極的に最適化しますが、コードサイズについてはまだ最適化していません。新しいARMバックエンドにより、コードサイズがより重要な組み込みシステムでLLVMを使用することへの関心が高まっています。 LLVMでのコード圧縮の実装に取り組むことに興味がある人は、コードサイズ最適化にリンク時最適化を使用することを説明したこの記事を読むと良いでしょう。
既存のLLVMインフラストラクチャを強化するプロジェクトに加えて、LLVMコンパイラインフラストラクチャに含まれていないソフトウェアを改善するプロジェクトがあります。これらのプロジェクトには、LLVMを使用するオープンソースソフトウェアプロジェクトと研究プロジェクトが含まれます。コアLLVMインフラストラクチャを強化するプロジェクトと同様に、これらのプロジェクトは多くの場合、やりがいがあり、挑戦的です。 少なくとも1つのプロジェクト（おそらくそれ以上）では、MachineFunctionPass内からの分析情報（コールグラフ分析など）を使用する必要がありますが、ほとんどの分析パスはLLVM IRレベルで動作します。場合によっては、値（関数ポインタなど）をMachineInstrレベルからLLVM IRレベルに確実にマッピングできないため、MachineFunctionPass内から既存のLLVM分析パスを使用することは不可能（または少なくとも不安定）になります。 このプロジェクトは、LLVM IRレベルからの分析情報を、MachineFunctionPassで利用できるように、生成時にMachineInstr IRにエンコードすることです。例は、コールグラフ分析（制御フローの完全性インストルメンテーション、コード再利用防御の分析、およびガジェットコンパイラに役立ちます）ですが、他のLLVM分析も役立つ可能性があります。 LLVM JITにオンデマンド関数リロケータを実装します。これにより、実行時のプロファイリング情報を使用してコードの局所性を向上させることができます。この考え方は、すべての関数にリロケーションテーブルを使用することです。すべての関数リロケーション時にリロケーションエントリを更新する必要があります（この記事をご覧ください）。 （関数ごとの）基本ブロックの並べ替えは、有用な拡張機能です。 このプロジェクトの目標は、参照アフィニティのモデルを使用して、より優れたデータレイアウト最適化を実装することです。この論文は、いくつかの背景情報を提供します。 Slimmerは、LLVMを使用して構築されたプロトタイプツールであり、動的分析を使用してプログラムの潜在的なパフォーマンスバグを検出します。 Slimmerの開発は2015年のGoogle Summer of Code中に開始され、初期プロトタイプにつながりましたが、プロトタイプの評価と移植可能で堅牢にするための改善はまだ必要です。このプロジェクトでは、学生がSlimmerの作業を引き継いで完了します。 Slimmerのソースコードと現在のドキュメントは、GithubのWebページにあります。 |