博士

ロボ子、今日はLLVMのインライン化について話すのじゃ。

ロボ子

インライン化、ですか。最適化の重要な要素ですよね。

博士

そうじゃ！でも、LLVMのインライン化の収益性を変えるのは一筋縄ではいかないらしいぞ。記事によると「変換と収益性分析のコードが密接に結合している」からじゃと。

ロボ子

なるほど、コードが複雑に絡み合っているんですね。変更を加えるには、全体像を理解する必要がありそうです。

博士

じゃが、LLVMのインライン化は他のパスよりも分離が良いらしい。「インライン化の決定は、InlineAdvisorを通じて行われる」とのことじゃ。

ロボ子

InlineAdvisorですか。そこでインライン化の判断がされているんですね。デフォルトの設定はgetDefaultInlineAdvice()で取得できる、と。

博士

そうそう。そして最終的にはgetInlineCost()が重要な役割を果たすのじゃ！

ロボ子

コストを計算して、インライン化の是非を決めるんですね。

博士

もしLLVMに全部インライン化させたかったら、InlineCost::getAlways("Decided by our majesty")を追加すれば良いらしいぞ！

ロボ子

全部ですか！？それはすごいですね。でも、本当に全部インライン化して大丈夫なんでしょうか？

博士

記事では、stb_imageライブラリを使ったC言語の画像処理コードをテストに使ったみたいじゃな。最適化を有効にするには-O3フラグを使うらしい。

ロボ子

-O3はかなり積極的な最適化を行いますよね。インライン化された関数とされなかった関数を通知するフラグもあるんですね。

博士

-Rpass=inlineと-Rpass-missed=inlineじゃな。試したらClangがクラッシュして、コンパイルに39秒もかかったらしいぞ！

ロボ子

クラッシュですか…。全部インライン化しようとすると、やはり無理があるんですね。

博士

__always_inline__属性を持つ関数はインライン化されるのは当然じゃな。

ロボ子

なるほど。属性で強制的にインライン化させることもできるんですね。

博士

"Decided by our majesty"というメッセージは、変更したコードが実際にインライン化されている証拠じゃ！

ロボ子

面白いメッセージですね。確認にはもってこいです。

博士

noinline属性は、関数定義に追加すると、オプティマイザにインライン化しないように指示できるんじゃ。

ロボ子

インライン化を抑制する属性もあるんですね。状況に応じて使い分ける必要がありそうです。

博士

stbi__out_gif_code()関数は再帰的なので、noinline属性が追加されたみたいじゃ。

ロボ子

再帰的な関数は、インライン化するとスタックオーバーフローの危険性がありますからね。

博士

ユーザーの決定を尊重するために、getAttributeBasedInliningDecision()が使われるらしいぞ。

ロボ子

ユーザーが指定した属性を優先するんですね。LLVMは賢いですね。

博士

しかし、全部インライン化はやりすぎじゃな。まるで、冷蔵庫にあるもの全部ぶち込んで作る料理みたいじゃ！

ロボ子

それは…、ちょっと怖いですね。でも、博士なら意外と美味しく作ってしまいそうです。