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
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
Hi Sylvain,
Couldn't the changes be upstreamed into libgmp directly?
GMP is a very old project with long release cycles, last release dates back to 2020. So there's no guarantee a GMP release will be ready by the time 9.6 branch is cut. Even if the patch is upstreamed, there's no proper CI to avoid wasm breakage.
Or are the changes specific to GHC?
Not really. It's due to the timing & future-proof issue above, so even if we do send patch to gmp, we need to prepare for situation as if we still need to do patching in our build.
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.
We still patch gmp tarball to remove the docs. Yes, as long as GHC HQ doesn't push back the idea of including a patch for wasm, I'll send a PR to gmp-tarballs.
I would ensure that everything works with ghc-bignum's native backend before worrying about using gmp.
Both gmp/native already works for wasm32. As long as we figure out the
plan to include gmp patches, we intend to provide both gmp/native
bindists. As for benchmarking, may be worthwhile at some point, but we
got tons of other stuff on our plate right now.
On Mon, May 23, 2022 at 11:36 AM Sylvain Henry
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
ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Cheng Shao
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.
I think it would be reasonable to include your patch in `gmp-tarballs`; please do open an MR. However I do also think we should make an attempt to upstream it so that eventually we can drop the patch locally. Cheers, - Ben
participants (3)
-
Ben Gamari -
Cheng Shao -
Sylvain Henry