Mercurial > hg > Members > kaito > slides

<!DOCTYPE html>
<html>
  <head>
    <meta charset='utf-8'>

    <script
       src='./trunk/slides.js'></script>
  </head>

  <body style='display: none'>
    <section class='slides layout-regular template-default'>

      <article>
	<h1>CbCコンパイラのLLVM3.4上での実装</h1>
        <p><br>Kaito Tokumori<br>October 8, 2013</p>
      </article>

      <article>
	<br>
	<h3>研究背景と目的</h3>
	<ul>
	  <li>関数呼び出しの際のオーバーヘッド解決<ul>
	      <li>Tail Call Elimination</li>
	      <li>継続による制御</li>
	  </ul></li>
	  <li>インライン展開について<ul>
	      <li>インライン展開によってオーバーヘッドが削減される点について</li>
	      <li>展開にも限度がある</li>
	  </ul></li>
	  <li>その他<ul>
	      <li>Cの一部を置き換えるCwCという方式を取ればCとの互換性がある</li>
	      <li>コードセグメント単位で分けると処理内容が明確</li>
	  </ul></li>
	</ul>
	<!--<p>
	  比較的歴史の古い言語であるCは普及率が高く多くのシステムに用いられている。そのCの問題のひとつに関数呼び出しの際のオーバーヘッドが大きいというものがある。当研究室ではこの問題をTail Call Eliminationの強制により解決しようと考えており、それを実現すべくCountinuation based C (CbC)という言語の開発を行なっている。CbCはCの関数呼び出しやループ制御の代わりに継続を用いて制御を行うもので、Cの下位言語に当たる。本研究ではmicro-c,GCC版に次ぐLLVMベースのCbCコンパイラ開発を行う。
	</p>-->
      </article>

      <article>
	<br>
	<h3>先週課されたもの</h3>
	<ul>
	  <li>研究目的をもうちょっとなんとか…</li>
	  <li>code segmentなのにcallされた時にエラーを出す。</li>
	  <li>createPruneEHPassによってどうしてjmpにならなかったのか</li>
	</ul>
      </article>

      <article>
	<br>
	<h3>エラーを出す</h3>
	<ul>
	  <li>SelectionDAGBuilder.cppのLowerCallTo関数でチェック</li>
	  <li>LowerCallTo関数でチェック<ul>
	      <li>LowerCallTo関数が呼び出す関数を辿って行くとTCEするかどうか調べる処理群にたどりつく。</li>
	      <li>LowerCallTo関数がCallLoweringInfoを作るときに呼び出す関数がTarget依存のようなのでここで調べるといちいちTarget毎に書かなくていい。</li>
	  </ul></li>
	  <li>callerとcalleeがcode segmentの時にtail call flagがfalseにされていたらerrorを出す。</li>
	</ul>
      </article>

      <article>
	<br>
	<h3>llvm::Typeについて</h3>
	<ul>
	  <li>errorを出させるときになぜかexit()がcode segmentと言われて怒られた。</li>
	  <li>llvm側のTypeは基本はvoidと同じようにして扱い、__codeであることがわかればいいことからis__Codeというflagを設けそれを用いて判断していた。</li>
	  <ul><li>なぜかcode segmentでない関数もis__Codeがtrueになっていた</li></ul>
	</ul>
      </article>

      <article>
	<br>
	<h3>llvm::Typeについて(解決編)</h3>
	<ul>
	  <li>原因：llvmのFunctionTypeが参照するReturnTypeは型毎に同じアドレスのオブジェクトを参照している！</li>
	  <li>なので一つのコードセグメントに対してFlagを建てた時に全てのvoid関数がコードセグメントとして扱われることになっていた</li>
	  <li>これより、flagを廃止して__CodeTyを作成する方向に変更。"include/llvm/IR/Type.h"でIDを定義して"lib/IR/Type.cpp"で関数を書く。</li>
	</ul>
      </article>

      <article>
	<br>
	<h3>エラー</h3>
	<ul>
	  <li>Emiterrorという関数をつかって出力できた。</li>
	</ul>
	<p><img src="./tailCallError.png"></p>
      </article>

      <article>
	<br>
	<h3>createPruneEHPassを通すとjmpにならない</h3>
	<ul>
	  <li>createPruneEHPassが実際のところなにをしているのかまではいまいち…</li>
	  <li>createPruneEHPassを通ると例の直後にreturnが来てるかどうかの部分でひっかかかる。<ul>
	      <li>unreachableになっていた。</li>
	  </ul></li>
	</ul>
      </article>

      <article>
	<br>
	<h3>createPruneEHPassを通すとjmpならない(回避策)</h3>
	<ul>
	  <li>unreachableの時にはGuranteedTailCallOptがtrueじゃないといけない。<ul>
	      <li>GuranteedTailCallOptをtrueにする場合、CallingConventionに制限がかかる。<ul>
		  <li>それを避けたくてGuaranteedTailCallOptを入れていなかった…。</li>
	      </ul></li>
	  </ul></li>
	  <li>どのCallingConventionでなければならないかはTarget Machineによって異なる。<ul>
	      <li>X86はFastCC,HiPE,GHC。ARMArch64はFastCCだけ。等</li>
	  </ul></li>
	</ul>
      </article>

      <article>
	<br>
	<h3>回避策としてCallingConventionをFastCCにした場合</h3>
	<ul>
	  <li>O0では特に問題なし。TCEもされる。エラーも出ない。</li>
	  <li>O2だと一部callのまま…。(factorialの場合複数あるprint_factorialのうち１つだけcall)</li>
	  <li>しかもエラー出ない。<ul>
	      <li>つまりTail Call Flagのチェック以後にcallにされている？</li>
	      <li>どちらにしてもエラーを吐く場所を変えないといけない可能性</li>
	  </ul></li>
	  <li>print_factorialが複数生成されているのはそういう最適化？</li>
	</ul>
      </article>

      <article>
	<br>
	<h3>次</h3>
	<ul>
	  <li>print_factorialがjmpにならない原因を探る</li>
	  <li>必要であればエラーを出力する場所を変更</li>
	</ul>
      </article>

    </section>
  </body>
</html>
author	Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
date	Tue, 14 Oct 2014 19:17:35 +0900
parents	2013/old/2013_10_8.html@845ff8ff4fc9
children