Hi Cheng, Couldn't the changes be upstreamed into libgmp directly? Other projects may benefit from being able to compile libgmp into wasm. Or are the changes specific to GHC?
- Send a PR to gmp-tarballs, including our patch (doesn't alter behavior on native archs) and the updated tarball build script
I'm not sure if it's still the case, but in the past we applied some patches to gmp before building it (to use fPIC and to remove the docs). So it should be possible to do it for wasm.
- Give up gmp completely, only support native bignum for wasm32.
That's the solution we will use for the JS backend. For wasm, it would be great to compare performance between both native and gmp ghc-bignum backends. libgmp uses some asm code when it is directly compiled to x86-64 asm for example and afaict passing through wasm will make it use less optimized codes. It may make the gmp backend less relevant: only benchmarks will tell. I would ensure that everything works with ghc-bignum's native backend before worrying about using gmp. Cheers, Sylvain On 20/05/2022 13:43, Cheng Shao wrote:
Hi all,
The ghc wasm32-wasi build needs to patch gmp. Currently, our working branch uses a fork of gmp-tarballs that includes the patch into the tarball, but at some point we need to upstream it. What's the best way to add these fixes?
- Send a PR to gmp-tarballs, including our patch (doesn't alter behavior on native archs) and the updated tarball build script - Don't touch gmp-tarballs, use "system" gmp, so the wasm32-wasi gmp build process is decoupled from ghc build - Give up gmp completely, only support native bignum for wasm32.
Cheers. Cheng _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs