ICFPCに初参加しました！

@xhl_kogitsuneさんに誘って頂き、今回ICFPCに初参加しました。
ので、感想とか反省とか少し書いてみます。
チームメンバは
@xhl_kogitsuneさん
@inouehさん
@thimuraさん
@mayahjpさん
@kazegusuri
と自分でした。

結論から言うと俺何もしてない！
(けど得点はいってた！)

初日(8月9日)

この日は休みを取っていなかったので仕事終わりから参加。
休憩時間等に軽く問題は見たけどあまりちゃんと把握していない状態で夜8時過ぎにメンバのもとへ到着。
そこにはThinkPadだらけの怪しい集団が。
着いたときには既に全列挙型のソルバができあがっていた。
一人出遅れた感がいっぱいでした。
とりあえずPC起動して問題開いて上からだだーっと見ていく。
同時にほぼ未設定だった自分のUbuntuさんの環境を構築して
用意してもらったリポジトリからソースをとって少し眺めたりしてましたが、そのままひとまずご飯を食べて解散。
帰宅後このままではまずいと思って何かしようと試みるも問題を読み直して概ね把握したところで寝落ち・・・

ちなみに@xhl_kogitsuneさんが一人頑張ってlightning divisionの得点を稼いでくれていた。
すごい！俺何もしてないのにポイント入ってる！みたいな。

二日目(8月10日)

壊れた携帯をdocomoショップに持っていったりしていて出遅れる。
メンバのもとへ到着したのは既に夕方・・・
この日は@xhl_kogitsuneさんと@inouehさんと@kazegusuriがいました
何やら@inouehさんと@kazegusuriは枝がりを頑張っている様子。
@xhl_kogitsuneさんは別方向を模索すべく調査中。
やばい俺何すればいいかアイデアが出てこない。仕事くれ！状態。
ひとまず助言頂いて自分も@xhl_kogitsuneさん側に参加。
何やらSMTソルバなるものがあるらしく@xhl_kogitsuneさんに
すごく大まかに概要を説明してもらって何となく触りだけ理解。
論文？でも読んでみよう開いてみたが一向に進まない！
やばい俺今日も何もしてないよ！の状態で解散
ちなみにこの日は晴海にいたのですが、花火大会とかぶって帰りの電車は混雑しまくり。
リア充爆発しろ。
帰宅後SMTソルバについてもう少し調べておこうと試みる。
Yicesなるものがあるらしいのでそれを少し見ていたが
うまく飲み込めないまま寝落ち・・・

三日目(8月11日)

この日も少し出遅れ15時ぐらい？に到着。
@xhl_kogitsuneさん、@inouehさん、@mayahjpさんがいた。
@inouehさんは積極的に枝狩りをがりがりと、
@mayahjpさんは追加問題用のソルバを書いている様子。
@xhl_kogitsuneさんはz3というSMTソルバに挑戦中。
到着早々またもや俺何しよう状態。
git pullしてソースもってきてとりあえず何かできないか考えていたがうーむ・・・
で、途中で@xhl_kogitsuneさんがEC2のインスタンスあげてくれたので
そちらにちょろっと環境入れてその時点のコードでトレーニング問題を解いてみる。

size30とかでもかなり浅い所に解がある場合も多いようで
列挙するリストサイズを@inouehさんがいれてくれたりしていた。
というわけで、その辺も含め、実際動かす時にヒューリスティックな部分でチューニングできるところとか
そういうのをリソースが潤沢なEC2上で確認するお仕事をはじめる。
が、トレーニング問題だけの特性なのか何なのか、特に人間が何かしてあげるべき部分がみつからない。
ノーマル問題であればほぼ確実に解けている。
逆に追加問題はどう頑張っても無理。(@mayahjpさん待ち)

隣で@xhl_kogitsuneさんから“z3でsize小さめのならとけたー”
という声が。
流石。。。という感じだけどどうもまともに使おうと思うとチューニングが必要なようで今回の導入は諦め。
途中で@thimuraさんがやってきて、通信周りのイケてない実装を修正してくれていた。

そうこうしているうちに@mayahjpさんが追加問題用のコードを完成させる。
トレーニングで試してみたりしてこれは本物っぽいという結論に。
これで大方戦う準備ができた？
やばいマジ俺何もしてない！

解散の少し前に実行時の問題指定があまり整理されていないことに気付いたので
ID指定で問題食わせるシェルスクリプトを書いていた
が、テストまでちゃんと終わらせられないまま時間切れ。
解散して帰宅。
俺の役立たず！

翌日はコミケにサークル参加だったので帰宅後はひたすら準備をする。
その間にもskype上では@inouehさんと@mayahjpさんが頑張って問題にあたってくれている。
@xhl_kogitsuneさんも途中から頑張って解いてくれていた。
うぬーわし何もやってない・・・

そのままC84三日目に行って帰ってきてskypeログみて何やら状況を確認。
あぁ・・・ほんとにみなさんお疲れさまでした。

反省

今回初参加だったのですが、俺ほんとに何もしてない・・・
って所で全てが終わってしまいました。
今思うとコアな部分には協力できなくても細かいところで色々できたはず。
(最後に作ってたシェルスクリプトなんて割と序盤にやっときゃもっと効率良かっただろうし
通信周りだって手が空いていたんだから何か手を入れられたかも)
あと、もっと積極的に発言すべきだった。
常に皆から遅れてる感じで、状況確認も含めて色々質問しておくべきだったし
くだらないことでも何か発言していくべきだった。
皆ちゃんと自分で“次こうやろう”というのを決めて行動してたんだけど
↑のこともあってずーっと“えっえっ俺なにしよう！？”って感じで進んでた。
一応、
どこかのループをGPUに投げつけたりできないかなー
とか
InputとOutputの値で絞り込み上手くできないかなーとか
考えたりしてたけどちゃんとした実装イメージができなくてうがーっとなって終わり。
(GPGPUはここ3年ぐらい触ってないし、そもそも分岐いっぱいで余り嬉しくなさそうだった)

総合するとまぁ経験も知識もテクニックも足りてなくて残念！
皆すごい！という感じかなぁ。

でもほんとに面白い問題だったと思います。
72時間の中でトライ&エラーで試行錯誤してチューニングして〜って所も。

もっと力をつけていつかリベンジだなぁ。

【報告】C84お疲れさまでした！

C84から少したってしまいましたが報告エントリです。

報告

C84は三日目東ペ-04aにて参加していました。
今回は平日ということもあってどれくらいの人が来てくれるかなー？
と心配していたのですが
多くの方に来て頂き、11:40ごろに無事完売となりました。
皆様ありがとうございました。
ただ、相変わらず完売後に来てくださった方も多くいたので
そのあたりは大変申し訳ありませんでした。
ここ二回は取り置きも導入してみてはいるのですが
それもあまり浸透していない？ようで
どうすればうまく頒布できるか考えていく必要がありそうです。。。

今後の活動

C85もひとまず申し込みしたので当選していれば何か出す予定です。
今のところは引き続きClangネタでいこうと考えていますが
詳細は今後考えていくかなーといった感じです。
内容がかなり概要部分で収まっていることもあり、
C84の頒布物については今のところ電子書籍化や委託は考えていませんが
今後それなりの内容に進化したら考えていきます。
(TwitterのTL等々監視していますがLLVM本の時ほど反響は無いようなので
もう少し内容を厚くしていかないといけないかなぁとか思ったりしています)

ひとまず「きつねさんでもわかるLLVM」電子書籍版のver1.00への更新や
インプレスジャパン様の紙媒体の方の対応など、
やるべきことが幾つか溜まっているのでそこからやっていかないといけませんね。

最後に

色々と課題はありますが、今後も頑張って活動していくのでよろしくお願いします！

【宣伝】C84にて「きつねさんとおぼえる！Clang」を頒布します【取り置きも受け付けます】






既に風ちゃんが宣伝してますが，C84の宣伝です．
取り置きの情報も記載していますので，興味のある方はご確認下さい．

しかし気づいたら一週間前とは何とも早い・・・

C84 頒布の本について

C84にて，きつねさんシリーズ新作の「きつねさんとおぼえる！Clang」を頒布します．
タイトルからもわかる通り，Clangの解説本になっています．

大項目として，Sanitizer，LibClang，LibTooling，ClangPluginを取り扱っています．
(コンパイラとしてのClangの機能はほぼほぼ説明していません)
なお，私の担当はLibToolingとClangPluginで，
風薬(id:sabottenda)がSanitizerとLibClang，矢上さん(web)が表紙です．
今回は時間的な問題でチュートリアルレベルの基礎的な内容ですが，
“Clangの各機能でどのようなことができるか”といった部分は紹介できているかと思います．

ちなみに，今回は本文の最後に表紙のきつねさん'sの設定資料が載っています．
今までの表紙詐欺に泣いていた，きつねさんを愛でたい人たちにも満足して頂けるのではないかと！


なお，頒布情報は下記のとおりです．

会場：東京ビッグサイト
日程：2013年8月12日
スペース番号：東 ペ-04a
頒布物：きつねさんとおぼえる！Clang
価格：1部 700円
※部数制限なし(150部持込)

取り置きについて

今回も前回に引き続き，取り置きの受付をしてみます．
(今回は150部あるので大丈夫かなぁと思うけれど)
前回同様，取り置きのルールは以下の通りです．

  • 取り置き専用エントリ(こちら)にて名前と必要な部数を申請してください
  • C84 当日は専用エントリに記入した名前をスペースでつげてください
  • 取り置きは最大14時頃までとし，14時までにいらっしゃらなかった場合は販売分にまわします

一応今のところ取り置きにも部数制限をかけるつもりはありません．
が，予想以上に伸びるような事があったら一旦受付をとめるかもしれません．

担当箇所について

私が担当した部分について簡単に説明しておきます．
自分担当箇所の目次は以下の通りです．

  • 第5 章LibTooling
    • 5.1 LibTooling とは
    • 5.2 ビルド環境の構築
    • 5.3 Clang AST の概要
    • 5.3.1 clang-check でast をdump してみる
    • 5.4 LibTooling で簡単なツールを作る
    • 5.4.1 コマンドラインオプションのパース
    • 5.4.2 ClangTool を生成して実行する
    • 5.4.3 コンパイルと実行
    • 5.4.4 独自のFrontendAction を作成する
    • 5.5 RecursiveASTVisitor でAST の情報を出力する
    • 5.5.1 RecursiveASTVisitor の作成
    • 5.5.2 ASTConsumer の修正
    • 5.5.3 コンパイルと実行
    • 5.6 LibAstMatchers で特定パターンのAST を捕捉する
    • 5.6.1 AST matcher
    • 5.6.2 clang::ast_matchers::MatchFinder
    • 5.6.3 clang::ast_matchers::MatchFinder::MatchCallback の作成2
    • 5.6.4 コンパイルと実行
    • 5.7 RefactoringTool でコードを書き換えてみる
    • 5.7.1 RefactoringTool の生成と実行
    • 5.7.2 MatcherCallback にReplacements を渡す
    • 5.7.3 MatchResult からAST のノード情報を取得する
    • 5.7.4 Replacement を生成する
    • 5.7.5 コンパイルと実行
  • 第6 章ClangPlugin
    • 6.1 ClangPlugin とは
    • 6.2 ClangPlugin で簡単なプラグインを作成する
    • 6.2.1 PluginASTAction の作成と登録
    • 6.2.2 コンパイルと実行

LibToolingから触り始めたのでそちらの話がメインとなっています．
LibToolingでは既存のFrontendActionを実行するところから始まり，
独自のFrontendActionの作成やASTMatcherの利用など，少しずつ機能を変更していく形で説明しています．

ClangPluginの方は簡単なプラグインの作成方法を説明しています．
ClangPluginではLibToolingとコードを共有できるという点も伝えたかったので，
5章で使用したソースコードを流用してプラグインを実装し，ロード/実行までを確認します．
そういった意味で，こちらは若干おまけみたいな内容になっていますね。。。

【〆ました】【C84】きつねさんとおぼえる！Clang 取り置き用エントリ

※2013/8/12 02:21
〆ました


C84 で頒布する“きつねさんとおぼえる！Clang”
の取り置き専用エントリになります．

基本的に前回と同様，下記のルールとしたいと思います。

  • 取り置き専用エントリ(本エントリ)のコメントにて名前と必要な部数を申請してください
  • C84 当日は専用エントリに記入した名前をスペースでつげてください
  • 取り置きは最大14時頃までとし，14時までにいらっしゃらなかった場合は販売分にまわします


というわけですので，取り置きを希望される方は本エントリにコメントをお願いします．


※一応今のところ取り置きにも部数制限をかけるつもりはありませんが，
あまりにも伸びるような事があったら一旦受付をとめるかもです．

取り置き受付済の方々

返信済みの方々を随時追記いたします．
部数等にお間違いがないかご確認お願いします．

【取り置き受付済の方々】
wakadannacom さん：1部
tell さん：2部
おおの さん：1部
finalfusion さん：2部
sassembla　さん：1部
わたなべ さん：1部
quote さん：1部
sudo さん：1部
onu さん：2部
夜道 さん：2部
morokosi さん：1部
ねこらぼ さん：2部
mist さん：2部
shinichi さん：1部
tkralia さん：1部
FLATSTONE：1部
Sakana さん：2部
erre_factory さん：1部
nullkal さん：1部
mtakagi さん：1部

仕事やめたいと思って同人活動を始めたらいつの間にか商業誌を出して頂けることになりました

きつねさんでもわかるLLVM ~コンパイラを自作するためのガイドブック~

きつねさんでもわかるLLVM ~コンパイラを自作するためのガイドブック~

発売まであと一週間を切りましたので、そろそろ宣伝させて頂きます。

C82にて頒布した「三日でわかるLLVM」から始まった
LLVMの初心者向け解説書がついに商業誌で出して頂けることになりました。
タイトルは達人出版会で公開中のタイトルにサブタイトルがついて、
「きつねさんでもわかるLLVM ~コンパイラを自作するためのガイドブック~」
になりました。
Trema本に
「誰もやってないことはよいこと」
というような事が書いてあるけど、これは本当にそうだなと思っていて、今回の本は
「LLVMの解説本としては初のものである」
という点については少し自信を持っていいのかな？とか思っていたりします。
紙媒体ということもあって電子書籍版と比較するとお値段が少し高くなってしまいますが、
どうぞよろしくお願いいたします。

内容は達人出版会様のv0.9.1版に幾つかの項目を追加し、
プロの方に校正をお願いしたものになります*1。
風ちゃんがサークル公式ページのカタログに紙版のページを用意してくれたので
詳細はこちらをご覧ください。
商業誌で出してもらえることになるというまさかまさかの展開で筆者一同驚愕しています。

同人誌から始まって、達人出版会様での電子書籍公開、
そして今回の商業誌出版と、書き始めた当初には全く考えてもいなかった展開の連続でしたが
おかげさまでどうにかここまでやってこれました

余談

さて、タイトルは半分ネタだけどほんとの話です。
以前ぽろっと呟いたことがあるけどLLVM本を書き始めた最初の理由は
「とにかく会社やめたい」
ということでした。
勿論それだけではないんだけども、
一昨年の夏ぐらいは本当に仕事が面白くなかったし、
なんとなく会社行きたくなーいって思ってて
でも仕事辞めるにしても何か自信を持って「これができます！」ってものがないとダメだよな
とも思っていて「何かやんないと！」という感じ。
そんなことを漠然と考えながら毎年恒例の夏コミに行って
「あー俺も何か出したい！同人誌書こう！」っという感じになりました
本というわかりやすい形で成果が出せるし丁度良いなと。
まぁそんな感じで特に深く考えてLLVM本を書き始めたわけではないけど
とりあえず今は毎日元気に会社に行っているし、
結果としてすごく多くの人に手に取ってもらうことができたので本当に良かったと思います。

ちなみに、「3日でできるLLVM」にも書いたけどLLVM本の執筆にあたってはCell本の影響をすごく受けてます。
同人誌作ろう！って思って真っ先に思い出したのはCell本でした。
Cell本は本当にすごいと思う。
よくまとまってたし、読み物としても面白かった。
これを読んだときから同人誌書きたいなと思ってたんだけど
思っただけでそこから数年動き出さないのが何とも俺らしいね。

自分のやっていることを何かしらの形にして人前に出すというのはそれなりにモチベーションにつながるし、
色んなすごい人たちとお話しできて、色んな事に興味を持つきっかけにもなるし、
同人活動は楽しいので皆さんもっと積極的にサークル参加すればいいと思います。
自分は技術的には色々未熟だけど、こんな自分でも時間をかければ一冊書ききれたのでやれば誰だってできるよ！
まぁ、圧倒的に時間はとられるし、金銭的にも辛い部分はあるけども、それを差し引いたって楽しいと思いますよ。
あ、でもそこそこストレスたまるんで覚悟した方がいいかも。

最後に

LLVMはじめたら彼女ができました。
(26歳、男性、会社員)

*1:達人出版会様の方もv0.9.2で同レベルのものにアップデートする予定です

LLVMのPoisonValueについて

2か月前にとりあえず書いたのに放置してしまってました！
ごめんなさいいいいいいいいいいいいいいい

C83で頒布した”きつねさんとおぼえるLLVM”に関して
hayamiz さんから下記のコメントを頂いておりました。

・Signed/Unsigned のオーバーフローって何？

このコメントを頂いた対象の文は

add 命令やsub 命令に現れるnsw やnuw は，No Unsigned Wrap とNo Signed Wrap の略で
それぞれUnsigned とSigned でオーバーフローが
発生した時にUndef Value(未定義の値) になるというフラグを意味します．

というものでした。

で、この質問の意図としては下記の二つがあるのかな、と感じたので
それぞれについて本エントリで修正と回答を書きたいと思います。

・Signed/Unsigned のオーバーフローって日本語としてわかりにくい
・Signed/Unsigned (の演算)でオーバーフローがおこるってどういうこと？

本文の表現について

まず、nswやnuwはオーバーフローが発生した時にPoison Valueになるというフラグなので
「add 命令やsub 命令に現れるnuw やnsw は，No Unsigned Wrap とNo Signed Wrap の略で
　それぞれUnsigned とSigned でオーバーフローが発生した時にPoison Value
　になるというフラグを意味します．」
というのが正しい文になります。申し訳ありませんでした。

で、”Unsigned とSigned でオーバーフローが発生”というのは
”Signed(符号付き)，もしくはUnsigned (符号なし)の整数演算でオーバーフローが発生”
ということを意図していました。
ひょっとすると日本語の表現として分かり難くなっていたのかもしれません。
申し訳ありませんでした。

Signed/Unsignedのオーバーフローについて

一般的にUnsigned(符号なし)整数はオーバーフローしないことになっていますが，
これは演算結果がUnsigned の表現できる範囲を超えた場合，最大値＋１を法とする剰余で表現する
というのが“決められている”からです．
整数演算の結果がオーバーフローする/しない，というのはアーキテクチャや処理系に依存するところで，
割と好きにしちゃえばいいところ（だと思う）

LLVMの話をすると，LLVM の整数演算命令，例えばadd 命令は
オペランドとしてinteger(整数型)，もしくはintegerのvectorをとりますが，
そもそもLLVM のinteger(整数型)はi1，i8，i32 のようにビット幅を表現するのみでSigned/Unsigned は区別しない。
たぶんadd命令はあたられたオペランドの値を足すだけで
オペランドがSignedかUnsignedかなんて意識してないと思う．

Undef ValueとPoison Value の違い

今回Undef ValueとPoison Valueを間違えて記載してしまっていたのですが，
そもそも両者の違いは何なの？というのがあると思います．
これに関しては，かなりざっくり言うとUndef Valueは値でPoison Valueはフラグという認識です．

LLVMのLanguage Reference Manualによると
「Poison ValueはUndef Valueと似たようなものだけど
　副作用起こしてはいけない命令で未定義の動作がおこったことを表せるよ」
という感じのことが書いてあって，コード例とともに挙動が記載されています。

Poison Valueは例えばFFFFFF ＋ 0000001みたいなaddがあった時は，
0が返るけど値はPoison Valueになっているというフラグがどこかにセットされる？
で，一度値がPoison Valueになるとその値を利用している演算には
Poison Valueであるというフラグが伝播していく，という感じに見えます．

Undef Valueについては，LLVMのValueのサブクラスを見ているとUndefValueというのがあるので，
UndefValueを生成して値として使用できるのだと思う．(実際にUndefValueを使ったことはないです)

NSWとかNUWって何に使用するの？

最後に。。。
NSWとかNUWがPoisonValueに関連してるらしいけど
じゃあNSWとかNUWとかのフラグって何に使ってるの？という話．
正直そこまでは私もよくわかっていないです。
実装を追っていけば何をやっているかが見えるかと思うのですが，まだ見きれていないです。。。
フロントエンドは粛々と言語仕様に基づいて命令作るだけでいいかなーという感じ。

きつねさんとおぼえるLLVM の訂正個所【2013年2月24日追記】

C83 にて頒布した
きつねさんとおぼえるLLVM
の訂正個所について、
読者の方から頂いたコメント、
および筆者が読み返して見つけたものを纏めました。
ご確認をお願いします。
(今後新たに訂正個所が見つかった場合は適宜追加します)

※本エントリは同人誌版の「きつねさんとおぼえるLLVM」の訂正箇所一覧です
　電子書籍「きつねさんでもわかるLLVM」の訂正一覧はこちらをご覧ください

repeatedlyさんから頂いた訂正個所とコメント

p6：
(誤)コンパイラ基盤はコンパイラ基盤を作るための〜
(正)コンパイラ基盤はコンパイラを作るための〜


p36：
【コメント】
for.condに到達する変数iの定義が複数存在
とあるが%iもint iも一度しか登場していない

【回答】
ご指摘ありがとうございます。
ご指摘の通り、"定義が"という表現は正確ではありません。
for.cond に到達する複数のブロック内で変数iに対する値の代入が行われる
ということを意図していました。


p64：
(誤)上記の構文図からもわかると思いますが，visitFunctionDeclaration とvisitFunctionDefinitionは
(正)上記の構文図からもわかると思いますが，function declaration とfunction de nfiitionは


p73：
(誤)visitAssignmentExpressionを再帰的に
(正)visitAdditiveExpressionを再帰的に


p95：
【コメント】
generateCallExpressionの処理内の10行目で
Function * func =Mod -> getFunction (" main ");
としているがmainではなくCurFuncではないか

【回答】
ご指摘の通り、CurFunc が正しいです。
Function * func =CurFunc;
が正しい処理となります。
コーディング時に仮で置いていた処理の修正漏れです・・・。


p111：list5.63 に対する行数
(誤)9行目、13行目、
(正)それぞれ13行目、17行目


p113：list5.65
(誤)dcc test.dc -o test.ll
(正)dcc test.dc -o test.ll -jit


p141：3行目，list6.2
(誤)getRequired
(正)getAnalysis


筆者側で確認している訂正個所

p7：コンパイラ基盤としてのLLVM Core 3行目
(誤)ユーザはLLVM は特定の言語やアーキテクチャに対する〜
(正)ユーザは特定の言語やアーキテクチャに対する〜


p15：trunk からソースコードを取得する場合のcompiler-rt の取得
(誤)cd ../llvm/projects
(正)cd ../projects


p15：■ビルドとインストール 内、インストールディレクトリの作成
(誤)mkdir /usr/local/llvm
(正)sudo mkdir /usr/local/llvm


p15：■ビルドとインストール 内、configure時の投入コマンド
(誤)../src/configure --prefix=/usr/local/llvm --enable-optimized
(正)../llvm-3.1.src/configure --prefix=/usr/local/llvm --enable-optimized


p15：Debug ビルド時のconfigure時の投入コマンド
(誤)$ ../src/llvm-3.1.src/configure --prefix=/usr/local/llvm --disable-optimized --enable-assertions --enable-debug-runtime --enable-debug-symbols
(正)$ ../llvm-3.1.src/configure --prefix=/usr/local/llvm --disable-optimized --enable-assertions --enable-debug-runtime --enable-debug-symbols


p40：下から４行目
(誤)正式な紹介は後の節で行います
(正)既に命令の紹介をしているので該当の文を削除


p41：1行目
(誤)range Metadata は後述するload 命令に付加できるMetaData です
(正)range Metadata はload 命令に付加できるMetaData です
　　(既にLoad命令は紹介しています)


p90：■generateFunctionStatement 1行目
(誤)generateFunctionStatement ではFunction のボディとを生成します
(正)generateFunctionStatement ではFunction のボディを生成します


p100：list 5.50内 8行目
(誤) if( InputFilename . length ==0){
(正) if(opt.getInputFileName().length()==0){


p109：6行目 注釈15の挿入位置
(誤)〜MachineCode ベースでJIT を行うのだと思います　の末尾
(正)次の文(〜JIT コンパイルの実行に嬉しいことがあるのではないかなと予想しています) の末尾


p126：表5.10 llvm::cl::OneOrMoreの概要
(誤)1回以上指定さ．
(正)1回以上指定される．


2013年2月10日追記
p144：生成した共有ライブラリをLLVM IRに適用する際のコマンド
(誤)opt -load easypass.so -mypass test.ll -S > /dev/null
(正)opt -load easypass.so -easypass test.ll -S > /dev/null


p145：debug-pass=Structureを付与してoptを実行する際のコマンド
(誤)コマンドが未記載となっている
(正)opt -load easypass.so -easypass test.ll debug-pass=Structure -S > /dev/null

tomoki_imai さんから頂いたコメント

p36：mem2regの適用コマンド
(誤)$ opt -S mem2reg loop.ll -o loop_reg.ll
(正)$ opt -S -mem2reg loop.ll -o loop_reg.ll

hayamiz さんから頂いたコメント

p25
【コメント】
Signed/Unsigned のオーバーフローって何？

【回答】
こちらは別エントリにて記載したいと思います。


p25
(誤)Unsigned とSigned でオーバーフローが発生した時にUndef Value(未定義の値) になる
(正)Unsigned とSigned でオーバーフローが発生した時にPoison Value になる


p27：表4.5 loadの書式
(誤)!¡index¿ = ! i32 1 align
(正)! = ! i32 1 align


p27：表4.5 LLVM のメモリアクセス演算子内，store命令の構文
(誤)
result = store [volatile] * [, align ] [, !nontemporal !] [, !invariant.load !]
result = store atomic [volatile] * [singlethread] , align
(正)
store [volatile] , * [, align ][, !nontemporal !]
store atomic [volatile] , * [singlethread] , align


p36：下から５行目
(誤)色々行った
(正)色々言った


p39：list4.14
(誤)￥00
(正)\00


p43：本章の概要
(誤)本章での説明では，〜が二回繰り返されている


p48：TokenSetクラスの実装
【コメント】
Setだと順序なしの集合を意味するので，クラス名はTokenStreamやTokenSequenceの方が良いのではないか

【回答】
コメントありがとうございます。
確かにクラス名はそちらの方が適切ですね。。。
既に公開して多くの人の目に触れてしまっているので，
簡単に変えていいのかなぁ。。。とも思うのでちょっと検討してみます．


p51
(誤)list5.7 冒頭のコメントのスタイルが他とずれている


参考資料
(誤)[4][5][6]の先頭にyearがついている
(正)yearは不要なので削除


2013年3月3日 追記

kariya_mitsuru さんから頂いたコメント

p54：list 5.8 AST の基底クラス
【コメント】
BaseAST のデストラクタが仮想関数になってないので、メモリリークが発生する

【回答】
ご指摘の通りです。
pull request で頂いた通り、BaseASTのデストラクタを下記のように修正するのが正しいです。
virtual ~BaseAST(){}


p57：list 5.9 各種ステートメントのAST
【コメント】
BinaryExprAST にデストラクタが無いので、メモリリークが発生する

【回答】
こちらもご指摘の通りです。
pull request で頂いた通り、下記のように修正いたします。
~BinaryExprAST(){SAFE_DELETE(LHS);SAFE_DELETE(RHS);}


p57：list 5.9 各種ステートメントのAST
【コメント】
NumberAST のデストラクタが定義されていない

【回答】
ご指摘ありがとうございます。
下記のデストラクタをNumberASTに追加いたします。
~NumberAST(){}


しかしこれは酷い・・・