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 <sylv...@haskus.fr> wrote: > > 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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
