とあるエンジニアの備忘log: 8月 2012

2012年8月4日土曜日

インライン関数まとめ

インライン関数についてややこしいところをまとめておきます。
結論から言うと、常に `static inline` を使え、ってことになります。

結果だけ知りたい人は以下は読む必要なし。

### 最初に ###

`inline` キーワードは関数callを高速化せよ、という指定であって、`inline` を付けたからといって、本当にインライン展開されるかはわかりません。

実際のところ、最適化オプションをつけていない場合、`inline` を付けても、一切インライン展開してくれません。
最適化オプションによらず、インライン展開を強制させるには `__attribute__((always_inline))` をつけるというやり方があります。

`-O1` オプションをつけた場合、明示的に `inline` がついている場合はなるべくインライン展開しようとするが、`inline`指定がないものについては インライン展開しないようだ。

`-O2` オプションをつけた場合、`inline`指定がなくても、インライン展開をする場合がある。static 関数や、非常に短い関数など。

続いて重要なのは、インライン展開された結果、展開された関数の定義コードが残るのか、消えるのかという点について。
ここを間違えると、リンク時に関数の多重定義でエラーになったり、逆に関数が未定義でエラーになったりします。

これについては [gcc のマニュアル](http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Inline.html)に説明があるので、ほとんどここに書いてあるとおりなのですが。

`-std=` の指定によって挙動が違ってくる部分もあるのだが、まず全体通して共通している部分から。

### ケース1 ###

static inline int inc(int *a)
    {
      return (*a)++;
    }

のように static 関数に `inline` がついた場合。
この場合、（`static inline` の方が static よりもスピード重視であることを除き）基本的に `inline` を付けなかった時と同じ扱いになる。

どういうことかと言うと、すべての関数 call がインライン展開されたときは関数定義は残らない。
インライン展開されないcall があったり、関数のアドレス参照があったりすると関数の定義は残ります。

ちなみに、以下のように `inline` をつけずに、`__attribute__((always_inline))`をつけ、最適化オプションなしでコンパイルした場合、インライン展開はされたが、関数定義は残った。普通はこういう使い方はしないだろうが。。

static int __attribute__((always_inline)) inc(int *a)
    {
      return (*a)++;
    }

### ケース2 ###

extern int inc(int *a);
    
    inline int inc(int *a)
    {
      return (*a)++;
    }

のように、 `inline` なしで宣言された後、 `inline` 付きで定義された場合。
（この例では、宣言の直後に定義を書いているが、普通は宣言の部分はヘッダーに書くはずです。）
この時も `inline` がなかった時と同じような挙動になる。
すべての関数callがインライン展開されたとしても、必ず関数定義は残る。

ここからは `-std=` の指定によって挙動が異なる。

### ケース3 ###

inline int inc(int *a)
    {
      return (*a)++;
    }

のように宣言はなくて、 `inline` 付きで定義された場合。
もしくは、宣言と定義ともに `inline` が付いている時。

`-std=gnu90` (gnu89) または `-fgnu89-inline` を指定しているときは
すべての関数callがインライン展開されたとしても、他のファイルからの関数callに備えて、関数定義は残ります。

一方、`-std=gnu99` または `-std=c99` が指定された時は、全く逆で、この関数定義はインライン展開用にしか使われません。そのため、`inline` 指定の関数定義は必ず消える。
最適化オプションをつけていないときはインライン展開されていないにも関わらず、関数定義は消えてしまう。

ちなみに、`-std=c90` のときは `inline` キーワードを認識しません。

これを書いている時点 (gcc version 4.7) では `-std=gnu90` がデフォルトです。
将来的には `-std=gnu99` がデフォルトになるそうですが。

### ケース4 ###

extern inline int inc(int *a)
    {
      return (*a)++;
    }

のように `extern` と `inline` が同時に指定された場合。

`-std=gnu90` (gnu89) または `-fgnu89-inline` の時は、この関数定義はインライン展開のみに使われ、関数定義は残らない。

`-std=gnu99` または `-std=c99` の時は、関数定義が必ず残る。

### まとめ ###

デフォルト (`-std=gnu90`)では、以下のような挙動になる。

1. `static inline`

すべての関数call がインライン展開されると関数定義が消える

2. `inline` なしの宣言 + `inline` 付きの定義

関数定義は必ず残る

3. `inline`

関数定義は必ず残る

4. `extern inline`

関数定義は必ず消える。

ただし、 `-std=gnu99` または `-std=c99` オプションをつけると 3 と 4 の扱いが逆転します。

以上のことからわかるように、ヘッダーファイルに書いてマクロ関数の代わりにできるのは 1 と 4 です。
2 と 3 はヘッダーに書いてしまうと、(そのヘッダーが複数のファイルからインクルードされていると）multiple definition でエラーになります。

1 をヘッダーに記述し、複数のソースからインクルードさせる場合、 -O1 以上の最適化オプションか、`__attribute__((always_inline))` が必要。
そうしないと、やはり関数の multiple definition でリンクエラーになる。

4 の使い方としてはヘッダーファイルにインライン展開用のコードを書いておき、一つのCソースに、インライン展開されなかった時用の定義を(extern inline を外して)書いておく。
ただし、記述が重複する上に、 `-std=` オプションによって挙動が逆転するので使いにくいです。

以上のことから、 1 が最も使い勝手がよく、インライン関数は `static inline` を使え、ということになります。

Linux Kernelのコードをみてもほとんど `static inline` になっています。
たまに `extern inline` がありますが。。。

2012年8月1日水曜日

FreeBSD のことはよく知らないのですが、FreeBSDのソースをダウンロードしてくると、Linuxと同じようなファイルが含まれています。

ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.0-RELEASE

からsrc.txzを取ってきて、解凍すると、
usr/src/sys/ofed/include/linux 以下に
Linux Kernel の include/linux とそっくりなファイル群があります。

ディレクトリ名からして、Linux の方が本家だと想像します。
Linux は GPLライセンス, FreeBSD は BSDライセンスなので、こんなことできるんですかね？

FreeBSDが勝手にLinuxをコピーしているのか、それともLinux Communityに許可もらったのか、事情はよくわかりません。

include/linux/ 以下には他のソフトにもそのまま転用できそうな部品になるコードが結構ある。

たとえば、
include/linux/kernel.h に含まれる container_of マクロ。
include/linux/list.h の連結リストの関数群などなど。

自前のソフト開発で、Linux からコードをコピーするとGPL汚染すると思いますが、FreeBSDに入っている同等コードをコピーすれば、BSDライセンスとして扱ってよいということでしょうか。
企業なんかだと、コピー開示義務があるかどうかの違いは結構大きいと思います。

Linux ライクな autoconf.h を簡単に作る

Linux の Makefile においては、.config ファイルの内容から
include/config/auto.conf
と
include/generated/autoconf.h
が作られる。

前者はすべての Makefile から include され、
後者は -include include/generated/autoconf.h としてすべてのCのソースに渡される。

Makefile でも Cのソースでも、同じ設定内容を参照できるようにするというアイデアは素晴らしいと思う。

自前のソフトでも同様のことをしたいが、Linux の scripts/kconfig/conf を使うほどでもないという場合、以下のように make の簡単なコードでほぼ同等のことをできる。

Makefile の実装例：

include .config

auto.conf: .config
@ ($(foreach v, $(filter CONFIG_%, $(.VARIABLES)), \
$(if $($v), echo $v='$($v)';))) > $@

autoconf.h: .config
@ ($(foreach v, $(filter CONFIG_%, $(.VARIABLES)), \
$(if $($v), echo \#define $v $(if $(filter y,$($v)),1,'$($v)');))) > $@

例えば、

CONFIG_FOO=y

CONFIG_BAR="abcdef"

CONFIG_BUZ=0x100

# CONFIG_QUX is not set.

という内容の .config を食わせてみる。

実行結果は以下の通り。

$ make auto.conf

$ make autoconf.h

$ cat auto.conf

CONFIG_FOO=y

CONFIG_BUZ=0x100

CONFIG_BAR="abcdef"

$ cat autoconf.h

#define CONFIG_FOO 1

#define CONFIG_BUZ 0x100

#define CONFIG_BAR "abcdef"

sed などで、 .config を parse してもよいのだが、make の .VARIABLES に定義済み変数が全部入っているので、そこから CONFIG_ で始まるものを抽出すれば簡単である。

.config 中で =y のものは、 autoconf.h では 1 に define される。

本家 Linux では =m のものは autoconf.h の方では (変数名)_MODULE が定義されるが、今回のサンプルには実装していない。

make の ifdef はわかりにくい

シェルにおいて
$ FOO=
とすると、シェル変数 FOO は空ではあるが、定義はされている。
変数 FOO を未定義にするには
$ unset FOO
としなければならない。
つまり、シェルスクリプトで、「変数が空」であることと、「変数が未定義」であることは明確に違う。

一方、make においてはこのあたりが紛らわしいというか、非常にわかりにくいと思うので、整理しておきたい。

make には ifdef という構文があるが、これの挙動を見てみる。

（実験1）
以下の内容の Makefile を用意する。

FOO=

all:
ifdef
@echo FOO is defined.
else
@echo FOO is NOT defined.
endif

実行すると以下のようになる。

$ make
FOO is NOT defined.

FOO=
のように、空文字を代入した場合、 ifdef は FOO を未定義だと判定した。

なるほど〜、makeにおいては
空の変数は未定義の扱いになる。
そして、make には unset がないから、変数を未定義に戻すには、空文字を代入すればいいんだ、と理解したくなるかもしれない。
だが、これは違う。

（実行2）
次の内容の Makefile を用意する。

FOO=

FOO ?= 1
BAR ?= 1

all:
@echo FOO = $(FOO)

@echo BAR = $(BAR)

この実行結果は以下のようになる。

$ make

FOO =

BAR = 1

?= というのは、変数が未定義の時のみ、右辺の値を代入してくれる。

実験結果を見ると、

?= は BAR は未定義と判定したが、FOO は定義済みと判定したことになる。

（実験3）

以下の内容の Makefile を用意する。

FOO=

all:

@echo $(filter FOO, $(.VARIABLES))

実行結果は

$ make

FOO

となる。

.VARIABLES という makeの変数には、使用中の変数が全部入っている。

大量の変数が入っているのだが、その中に FOO も含まれていることがわかる。

つまり、 .VARIABLES には中身が空の変数も含めて、定義済みの変数がリストされている。

(実験1)〜(実験3)からわかることは、

makeにおいても、「変数が空」であることと「変数が未定義」であることは区別している。

（ただ、シェルと違って、いったん定義された変数を未定義に戻すことはできない。）

?= は変数が「未定義」であれば右辺値が代入される。

注意しておきたいことは、(実験1)からわかるように、 ifdef は「定義されているか」を判定するのではなく、「空でないかどうか」を判定するものだ。

これは、ひじょーーーーーに紛らわしい。

この ifdef の仕様は失敗じゃないの？と思う。

つまり

ifdef FOO

は

ifndef ($(FOO),)

と同じなのだ。

だから、 ifdef 自体、別になくても構わないし、私は使わない。