Remove integer-gmp / ghc-bignum dependency

[Bodigrim]

...and associated flags/CPP.

[sjakobi]

Wow, what a nice simplification! :)

How does it affect performance?

[Bodigrim]

Replacing quotRemInteger by quotRem and unboxed tuples by boxed does not incur a measurable performance regression. I believe GHC optimizes this stuff under the hood, it is very simple worker-wrapper transformation, and anyways at this point division costs trump everything else.

Surprisingly, toIntegralSized appeared to hit performance on short Integer by ~25%. I replaced it with an old-school fromInteger / toInteger, and now performance is back to baseline.

[sjakobi]

Surprisingly, toIntegralSized appeared to hit performance on short Integer by ~25%. I replaced it with an old-school fromInteger / toInteger, and now performance is back to baseline.

I think that might be worth reporting as a perf bug.

[Bodigrim]

@sjakobi Does removing a flag constitute a breaking change? Shall I retain integer-simple flag (doing nothing) for 0.11 branch?

[sjakobi]

@sjakobi Does removing a flag constitute a breaking change? Shall I retain integer-simple flag (doing nothing) for 0.11 branch?

Good question! My guess would be that Cabal flags are "part of the API" in a way, and therefore changing them is a breaking change. I've opened haskell/pvp#33 to be sure.

Maybe wait with the backport for now…

[hsyl20]

Does removing a flag constitute a breaking change? Shall I retain integer-simple flag (doing nothing) for 0.11 branch?

This change should only impact GHC afaict and we can easily drop this flag from GHC's build system when we will bump the bytestring submodule. I would just remove it.

[sjakobi]

I'm convinced. Let's not treat this as a breaking change.