GHCに初めてコントリビュートした／最近のGHC動向

事実上の標準デファクトスタンダードなHaskell処理系であるGHCに貢献するというのが去年掲げた目標だったが、それがようやく実現したので報告する。ついでに、最近のGHC開発状況についても簡単にまとめてみる。

「貢献」と言っても色々あって、バグ報告とかも立派な貢献なのだが、ここで目標としていたのは「書いたコードをGHC本体に取り込んでもらう」ことである。

一つ目：fromInteger :: Integer -> {Float,Double}

年末に書いた記事

Haskell/GHCでの浮動小数点数の扱い – Qiita

にあるように、現行のGHCのfromIntegerは値の大きさによって丸め方法が違っている。それによってどういう問題が引き起こされるかというと、

import Numeric
import Data.Word

main = do
  putStrLn $ "literal : " ++ showHFloat (0xFFFFFFFFFFFFFC00 :: Double) ""
  putStrLn $ "fromInteger : " ++ showHFloat (fromInteger 0xFFFFFFFFFFFFFC00 :: Double) ""
  putStrLn $ "fromRational : " ++ showHFloat (fromRational 0xFFFFFFFFFFFFFC00 :: Double) ""
  putStrLn $ "fromIntegral/Word64 : " ++ showHFloat (fromIntegral (0xFFFFFFFFFFFFFC00 :: Word64) :: Double) ""

というコードを書いた際に

最適化なしの出力：

literal : 0x1p64
fromInteger : 0x1.fffffffffffffp63
fromRational : 0x1p64
fromIntegral/Word64 : 0x1.fffffffffffffp63

最適化ありの出力：

literal : 0x1p64
fromInteger : 0x1.fffffffffffffp63
fromRational : 0x1p64
fromIntegral/Word64 : 0x1p64

という風に

リテラルとfromIntegerで結果が食い違う
fromIntegerとfromRationalで結果が食い違う
fromIntegralの結果が最適化の有無で変わる

という事態になっていた。

なので、fromIntegerの実装を修正した。

Make fromInteger use round-to-nearest-even for Float and Double (!4828) · Merge Requests · Glasgow Haskell Compiler / GHC · GitLab

このMRを出したのは1月だったが、昨日ぐらいにようやくmergeされた。上手くいけばGHC 9.2に反映される。

二つ目：AArch64での呼び出し規約

昔書いた

【低レベルHaskell】Haskell (GHC) でもインラインアセンブリに肉薄したい！ – Qiita

にあるように、GHCは内部的に独自の呼び出し規約を使っている。詳しいことは

https://gitlab.haskell.org/ghc/ghc/-/blob/master/includes/stg/MachRegs.h

を見て欲しいのだが、よくある「最初の数個はレジスター渡し、残りはスタック渡し」という感じになっている。

で、MachRegs.hを見る限りAArch64では単精度に4つ、倍精度に4つのレジスターをそれぞれ使うように見える……のだが、実際はそうなっておらず、倍精度の3つ目以降の引数・返り値はスタックで渡されるようになっていた。

まあGHCを普通に使う分にはこんなこと気にしなくて良いし、それこそアセンブリー直書きでforeign import primを実装でもしない限り発覚しなかったのだが、筆者がアセンブリー直書きを試みたために白日の下へ晒されることとなった。

この問題は1年くらい前に筆者が報告し、

Fewer FP registers than available are used for parameter passing on AArch64 (#17953) · Issues · Glasgow Haskell Compiler / GHC · GitLab

最近筆者が投げたMRで修正された。

Support auto-detection of MAX_REAL_{FLOAT,DOUBLE}_REG up to 6 (#17953) (!5117) · Merge Requests · Glasgow Haskell Compiler / GHC · GitLab

修正自体はほんの数行で済むのにこんなに時間がかかったのは、テストケースを用意するのが面倒だったからである。これもGHC 9.2で反映される見込みだ。

こっちは2月にMRを出してから割とすぐにapproveされてマージされた。なので筆者にとって初めてmergeされたのはこのMRとなる。

GHCのマージプロセス

GHCに投げたMRが取り込まれるには

レビューを経てapproveされる
CIが通る

の2つが必要だ。まあ大きめのプロジェクトならどこでもそうだと思う。ただ、GHCの場合は特に2番目（CI）がなかなか厄介で、謎の理由で失敗したりする。パフォーマンス特性が変わる？とアウトっぽい。

時間のかかるCIがランダムに失敗するとかなり虚無なので、開発者陣の間でも問題視されている（The ghc-devs March 2021 Archive by thread の「On CI」というスレッド）。

まあそれは置いておいて、MRがapproveされてCIが通ったとしよう。普通のプロジェクトならそのままマージされるのだろうが、GHCの場合は一旦Marge Bot預かりになる。GHCのMR一覧

Merge Requests · Glasgow Haskell Compiler / GHC · GitLab

を見ると上の方に「Marge Bot Batch MR – DO NOT TOUCH」というのが見えるはずだ。

筆者は詳しい事情は知らないが、Marge Botというのは複数のMRに対して一括でCIを回し、マージ作業を行うbotのようだ。Marge Botにマージされた場合は元のMRは（Mergedではなく）Closed扱いになるっぽい。

おわり

筆者がHaskellを使い始めて10年以上になる。その間、ただ使うだけではなく、（日本語）記事を書いたりパッケージを作ったりして、Haskellコミュニティーに貢献するように心掛けてきた。そして今回ついに「GHCに貢献する（自分の書いたコードを取り込んでもらう）」ことができ、達成感を感じている。

今回、筆者が投げていたMR 2つがマージされて一段落したわけだが、GHCに対するパッチのネタは他にもいくつか持っているので、そのうちまたMRしたい。

ところで、去年掲げていた「GHCに貢献する」という目標が去年のうちに叶わなかったのは、当時筆者が持っていたマシンが2013年モデルとかで、性能が劣る（のでビルドに時間がかかる→ビルドが億劫になる）という要因が大きかったように思う。この点に関しては、去年の年末に新しいMacを2台（Intel MacとApple M1 Macをそれぞれ1台ずつ）手に入れたので、GHCのビルドはの心理的な障壁が下がった（具体的には、quickビルドが1時間未満で済むようになった）。強いマシンは正義である。

Spread the love

雑記帳

人生やっていき

GHCに初めてコントリビュートした／最近のGHC動向

一つ目：fromInteger :: Integer -> {Float,Double}

二つ目：AArch64での呼び出し規約

GHCのマージプロセス

最近のGHC動向

Apple Silicon対応

GHC 9.0系

GHC 9.2系

おわり