What to do with gmp wasm fixes

[Cheng Shao]

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 <sylvain at 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 at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs