GSoC 2019 (LLVM) に採択された

概要

LLVMのGSoCに通ったので頑張りたい。

プロジェクト

プロポーザルは以下(個人情報はお気持ち程度に抜いている)

docs.google.com

プロポーザルに大体書いてあるがプロジェクトを要約すると

  • LLVM-IRにおいては関数（など)の性質(ex. "この関数はメモリを読み書きしない", "この関数は例外を投げない", "帰ってこない")を示すAttributeというものがある(https://llvm.org/docs/LangRef.html#function-attributes)。
  • Attributeは関数の最適化に用いられている。これはフロントエンド(ClangとかRustとか)が関数に添付することができるがすべてフロントエンド側に投げるのはフロントエンド側のコストが高く非効率である(メモリの読み書きの有無とかならLLVM-IR上で分かる)。
  • そこでLLVMミドルエンドで推論するのが自然な発想でありいくつかのAttributeに関しては実装されている(http://llvm.org/doxygen/FunctionAttrs_8cpp_source.html)。
  • 推論の仕方としてはCalling Graphの SCCの下から伝搬させていくのが自然な実装である。既存実装を見ると分かるが各Attributeに対して別々にSCCをtraverseするようなコードが書かれておりカオスな感じになってる。
  • そこで ⚙ D59918 [Attributor] Pass infrastructure and fixpoint framework で提唱されている"Attributor"というフレームワークを用いて再実装しようというのがプロジェクトの大筋である。
  • Attributorは関数の性質を伝搬させるのを不動点に至るまでぶん回すみたいな物になっておりデータフロー解析に似た挙動をする。

    Organization

    LLVMを選んだ理由としてはCPU実験でそこそこLLVMを使ったのと産業で用いられているコンパイラのミドルエンドでの最適化に興味があったのであんま迷わなかった。ちょっと迷ったのはChapelとSwiftだけどLLVMで落ち着いた。CPU実験のおかげである程度フロントエンド、バックエンドをいじっていたので環境構築とかはそんな困んなかった。ビルドに時間がかかりすぎて困ってる（まあ流石にフルビルドをそんなしないやろと信じてる）。

    応募した感想

  • Grammarlyは偉い
  • プロポーザルにフィードバックは貰えなかったけどどうにかなる（メーリスに投げてコメント0だったのでちょっと寂しかった）
  • Twitterとかで公開してる人のプロポーザルとか見るとn(>10)ページあってビビったりしてたがいうて要点つかめてたら大丈夫っぽい
  • マージされたパッチ無かった()けど通ってよかった(流石にパッチは投げた)

ブログを書いてしまい引くに引けなくなったので完走できるように頑張りたい（なお演習3(kbys研...))(普通に完走できるか怪しい）.