QBE - コンパイラバックエンド: バージョン 1.3

 (c9x.me)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • 性能最適化が大幅に追加され、QBE 1.3 は素の coremark で商用コンパイラ性能の 63% 以上を記録し、Hare テストスイートでは qbe-1.2 比で 33% 改善
  • QBE 1.3 は 1.0 以降で最大のリリースで、約 7k 行追加 と 1.5k 行削除を含む
  • 新しい最適化には GVN/GCM、ループ最適化、if 除去、CFG 単純化などが含まれるが、検証済みの一部パスのみが維持されている
  • インライン化は QBE の 関数単位ストリーミングコンパイルモデル と相性が悪いため、今回の最適化セットからは除外
  • ee_isdigit をインライン化し、crcu8 をより単純な分岐なし実装に置き換えた coremark 派生版では、QBE は目標としていた gcc -O2 比 70% の性能に到達
  • 新しい OCaml ツール mgen は lispy IL パターンを C のマッチングコードにコンパイルし、既存の手作業による命令選択ロジックを置き換えたり簡素化したりできる
  • mgen は特別なコメントブロック内の IL パターンを見つけ、その直下に C コードを挿入する。現在の使用例は isel.c にある
  • 命令 DAG マッチングは Ken Thompson の Plan9 C コンパイラ方式に近い番号付けアプローチに従い、runmatch() が解釈する単純なバイトコードマッチャも生成される
  • Windows ABI サポートが追加され、-t amd64_win を渡すと Windows 向けコンパイルが可能になった
  • QBE が生成するアセンブリは依然として AT&T 構文であり、mingw アセンブラでコンパイルする方法が適していると案内されている
  • 位置独立コードのサポートが改善され、ほとんどのターゲットで共有オブジェクトとのリンクや共有オブジェクト生成がより円滑になった
  • 新しい extern 動的定数フラグ (DYNCONST) により、IL レベルで動的ライブラリ変数のようなグローバルシンボルへの間接アクセスを表現できる

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Lobste.rsの意見

  • 長年続けている趣味プロジェクトとして、TRIPOS/Amiga Execスタイルの小さなOSを作っている
    メモリ保護はなく、フラットなメモリマップで、メッセージパッシングもポインタを渡す程度のもの
    こうしたシステムをセルフホストするには、PIE/PICを生成できる小さなコンパイラのほうがずっと扱いやすい。Amigaスタイルのライブラリは当然PICである必要があるし、実行ファイルを共有メモリマップのどこかに載せるとき、ロード時のパッチをあまり大量に当てなくて済むのも良い
    GCCとClangでも可能だが大きすぎる。最後に確認したときはTCCはPICに対応しておらず、QBEをもっと見てみる必要がありそう

    • 自分のCコンパイラは PIC を生成できるので、興味があるかもしれない: https://codeberg.org/lsof/antcc/
      自己宣伝のように聞こえなければよいのだが。小さなコンパイラという分野が本当に好きで、もっとテストも必要としている
    • 自分もフラットなメモリマップ、全面的にPIE、システムコールが関数呼び出しになっているOSの Ashet OS を作っている
      すでにかなり進んでいて、複数のプラットフォームをサポートしている
      近いうちにセルフホストまで行くのは難しそう。Thumb-2コード生成が必要で、これを実現する方法は実質的に自前のコンパイラを書くしかないからだ。カーネルコードを除くと利用可能なRAMは8MBしかないという制約もある
      ELFファイルを変換して作る独自の実行ファイル形式 .ashex を使っている。この過程で、実質的には絶対ジャンプ1つだけの特別なセクションを消費し、アプリローダーがそれを実際のシステムコールアドレスに書き換える
      フラットメモリシステムの難しさは、共有オブジェクトをきれいにサポートすることにある。異なるアプリケーション間でコードを共有するには、すべての動的シンボルアクセスがレジスタに保持された変数を通じて行われるよう、コンパイラ側の支援が必要になる

  • 新しい extern キーワードが追加されたのは本当にうれしい
    リリースノートにはないが、これが thread とも一緒に動作するので initial-exec TLS が可能になる。他の共有ライブラリで定義されたスレッドローカルなグローバル変数にアクセスするときに必要で、FreeBSDの ctype.h に必要になる
    extern は macOS や Haiku のようなプラットフォームで、共有ライブラリ内の通常のグローバル変数、たとえば stderr にアクセスするときにも必要になる。これでQBEベースのコンパイラは、ずっと多くのOSやユースケースをサポートできるようになる
    Rolandの性能改善にもとても感謝している。本当に素晴らしい仕事だ

  • これを正しく読めているなら、正式なWindowsサポートが入ったということか？
    QBEの歴史的かつ現在までの大きな制約の1つはここではなかったか？ 本当に喜ばしい

  • このプロジェクトの目標は Cranelift と重なっているのだろうか？ いつQBEを使うのか、いまひとつピンと来ない

    • QBEはコンパイラバックエンド界の「OpenBSD」に近い。単純さとミニマリズムが哲学で、公式説明によれば「産業用最適化コンパイラ性能の70%を、コード量10%で提供する」ことが目標だ
      競合相手は実際にはCraneliftとLLVMだ
      残念ながら過去には主に趣味言語やコンパイラ実装で使われていた。たとえば新しいC系言語のように見えた myrddin は今では死んだようで、cproc はまだ生きている趣味のCコンパイラ実装だ
      それでも HareがQBEを採用してからは期待が持てるようになった。質問への答えはここにある: https://harelang.org/documentation/faq.html#why-qbe-instead-of-llvm
    • CraneliftだけでなくLLVMとも目標は重なっていると思う
      詳しくはよく知らないが、比較資料は多い。知る限りではQBEは他の2つよりもはるかに単純なバックエンドを志向している

  • 命令選択マッチャーを生成するのに小さな DSL を使う方式が本当に見事だ