透過的なLLVM (7)

ほとんどもう、透過的にLLVMを使うことができるようになった。

• 透過的なLLVM (1)
  LLVM-GCCが内部的に呼びだすコマンド
• 透過的なLLVM (2)
  最適化オプションと実行可能ファイルの形式
• 透過的なLLVM (3)
  デバッグ情報の扱い
• 透過的なLLVM (4)
  動的リンクライブラリの扱い
• 透過的なLLVM (5)
  Apple libtool
• 透過的なLLVM (6)
  CentOS 4におけるGCCのバージョンミスマッチ

Mac OS X 10.5 (darwin9) では、メディアを扱うライブラリやツール、つまり圧縮や暗号化は確かに高速になる。32bitで試した範囲ではGNU/Linuxシステム、畢竟ELF形式もビルドに問題はなさそうだ。ビルドに問題はないが、速度が向上するとは限らない。メディアを扱うライブラリやツールは、しばしばアセンブリ言語で高速なコードを記述する。Native codeがまざるとLLVMの魔法が効きにくくなる。

OpenSSLが良い例だ。OpenSSL 0.9.8iのcpuid命令の実装は、アーキテクチャごとに4個のファイルを用意している。

• crypto/ia64cpuid.S
• crypto/sparccpuid.S
• crypto/x86_64cpuid.pl
• crypto/x86cpuid.pl

さまざまのアセンブラに対応するべく、x86-64とx86はアセンブリコードを生成するPerlスクリプトとして記述されている。対応するアセンブラにELF形式は含まれるが、Mach-O形式は含まれない。つまり、Darwinで普通にビルドしたOpenSSLはもろもろのハッシュ、AESやらDESやらをCで書かれたコードで計算している。LLVMの魔法は最大の効果を発揮するだろう。

GNU/Linuxシステムで透過的にLLVMを使用するためには、no-asm付きで./configを実行する羽目になる。静的リンクライブラリはbitcodeとnative codeを同時に含むことができない。静的リンクライブラリはbitcodeとnative codeを同時に含むことはできる（というか含んでしまう）けれど、単純には正しくリンクしてくれない。アセンブリ言語でかりかりに高速化された暗号化にたちうちすることは、さしものLLVMにも難しいようだ。openssl speedで調べた限りでは。

いくつかの解決策があるだろう。

• native codeからbitcodeへの変換
  参考: x86toLLVM?
• インラインアセンブラへの変換
  参考: Module-Level Inline Assembly, Inline Assembler Expressions
• LLVMの静的リンクライブラリの形式を変更する
• bitcodeとnative codeで別々に静的リンクライブラリを分割生成
• 正しくリンクしてくれるようにハックする。

前者ほど最適化の可能性が高く、透過的であり、しかし、実装が困難である。