CbCコンパイラのLLVM3.5上での実装

Kaito Tokumori
January 14, 2014

研究目的

　当研究室ではプログラムをコードセグメント、データセグメントという単位を用いて書くという手法を提案している。その手法を用いてプログラミングを行う言語として"CbC"の開発を行っており、これはCの下位の言語である。CbCにおいてコードセグメント間の移動はgoto文を用いた軽量継続によって行われ、これはTail Call Eliminationという最適化の強制によって実現される。

本研究過去に開発されたmicro-c,GCC版のコンパイラに続くLLVM/Clang上でのCbCコンパイラの開発を行う。

今回したこと

• 環境付き継続の実装
  • setjmp部分の構文の生成
  • 環境を保持する変数の自動生成
  • 元の関数に戻るコードセグメントの生成

環境を保持する変数群の自動生成

• __environmentを解析するときに生成。
• __CbC_environment, buf, retvalの宣言は__returnと同様にできる。
• __CbC_environmentのメンバへbufとretvalのアドレスをもたせるのもここで。

setjmp部分の構文の生成

• __returnか__environmentを解析するときに生成。
• if文の生成はIfScopeを作ってその中に入ってStatementを生成していくだけで良い。

元の関数に戻るコードセグメントの生成

• __returnか__environmentを解析するときに生成。
• 一旦今のスコープ(FunctionScope)を抜けて、トップのスコープに入る必要がある。
• スコープ以外に、FunctionScopeInfoの初期化をしてContextもTranslationUnitDeclに切り替えないといけない。
• それから作り始める。PrototypeScope,BodyScopeの順に作る。できたら上のみっつを元に戻す。

ユニークなシンボル名をつけるには(1)

• IdentifierInfoTableは名前だけを持っている。型とかスコープとかの違いはない。多分余計にIdentifierInfoオブジェクトを作りたくないだけ。
• LLVM IRに変換されるときに作られるSymbolTableが重要？
• SymbolTableは関数ごとにある。ファイル全体のものもあって、これで外のスコープの同じ名前ものと被らないようになる。
• こいつに値を登録するときに、reinsertValueという関数によって名前の衝突が解決される。
• DeclオブジェクトがIdentifierNamespaceというのを持っていてこれでラベルの名前なのか変数の名前なのかとかが判別できるみたい。

ユニークなシンボル名をつけるには(2)

• CbC用のIdentifierNamespaceを作れば、構文解析の最中に名前衝突でおこられない(はず)
• ただし、reinsertValueはこれより前のシンボル名と衝突しないことは保証するが後については保証しない。

環境付き継続TODO

• シンボル名
• setjmp.hの警告の処理
• 元の関数の型を調べて変数などを生成する