Closed Bug 1491098 Opened 6 years ago Closed 5 years ago

Link libgmp into SpiderMonkey, to support BigInt

Categories

(Core :: JavaScript Engine, enhancement, P5)

enhancement

Tracking

()

RESOLVED INVALID

People

(Reporter: jorendorff, Unassigned)

References

Details

Attachments

(2 obsolete files)

      No description provided.
Blocks: js-bigint
Priority: -- → P1
Summary: libgmp → Link libgmp into SpiderMonkey, to support BigInt
See js/src/vm/BigIntType.{h,cpp} for all places where libgmp is used. This code is currently behind #ifdef ENABLE_BIGINT. (And as a result, it's a bit dodgy to find using SearchFox.)

Background: BigInt is a new standard-track JS feature. Until now, JS has only had floating-point numbers. BigInt adds arbitrary-precision integers. This is useful for cryptography, codecs, interacting with Wasm -- anywhere you'd use a 64-bit int. Also handy when using JS as a compilation target for source languages that have real integers. Robin Templeton of Igalia is implementing it for SpiderMonkey. We're in the process of landing those patches.
We've been discussing this a bit on IRC, but I'll summarize here for the record:
* libgmp is GPL/LGPL licensed, so we can't statically link it. This was discussed a bit in bug 1366287.
* We have precedent for this, we currently ship a `liblgpllibs` shared library with Firefox with other LGPL licensed code: https://dxr.mozilla.org/mozilla-central/source/config/external/lgpllibs/moz.build
* We don't currently have anything that does this for Spidermonkey, though, so we'd have to sort out the issues there. This would likely mean just linking libgmp into `liblgpllibs` for full browser builds and linking the JS shell against that lib as well, and then figuring something out for standalone JS builds. (Supporting `--with-system-gmp` would probably make life easier for embeddors.)
* Dynamically linking this code does mean that there are performance implications: we'll lose out on inlining and LTO between Spidermonkey and GMP at the very least.
I'm starting to take a look at this.
Assignee: nobody → mshal
Just chatted with Michael on IRC. Let's put this on hold, in light of bug 1494346.

Currently, I expect we will WONTFIX this. We'll know in a few weeks' time.
Attachment #9016725 - Attachment is obsolete: true
MozReview-Commit-ID: USQbjPW2KC

Bug 1491098 - Import files generated during gmp build.

These are cross-platform. Another option would be to generate these via
HostSimplePrograms, but that seems to only work well with .c files in
the same directory as the moz.build file, so that would also require
some mozbuild work.

MozReview-Commit-ID: 11tn7xN4rJX

Bug 1491098 - Add gmp moz.yaml file

MozReview-Commit-ID: HqFBs4ziGbl

Bug 1491098 - Add gmp moz.build files (WIP)

Most of the moz.build files are created manually by analyzing what files
are built during a normal './configure && make' build of the upstream
libgmp library. The exceptions are mpn/moz.build and mpn2/moz.build,
which are auto-generated from config_links.py and the config.status file
generated by libgmp's configure.

The mpn directory is special because:

1) It contains platform-dependent code
2) It compiles some .c files multiple times with different -D flags
  (eg: sec_aors_1.c is compiled as sec_sub_1 and sec_add_1)
3) It contains .asm files, which are compiled by first preprocessing the
.asm with an m4 wrapper script (m4-ccas).

Part 3 is not implemented yet in this patch, as it is a WIP.

Additionally, the mpn-generated moz.build files will need to be
generated for each platform, and stored in platform-specific
directories. (Eg: mpn/moz.build should really be mpn/linux.mozbuild, and
mpn/moz.build can include the right file based on the platform). I was
planning to get Linux working first and then extending to other
platforms.

MozReview-Commit-ID: ARnSpbeoaDM
I tried to attach my WIP in case we need to come back to this, but I couldn't get the actual gmp source import patch to work (bugzilla complained that it's too large, and phabricator had some issue with UTF-8 or something).

In any case, most of the remaining work is in finishing up the gmp/mpn moz.build files to support .asm (with it's m4-ccas wrapper script), and also split up the mpn moz.build files to support other platforms, since each platform has its own specific set of files that it compiles in this directory. The config_links.py script is intended to generate these files from each platform's config.status file (which means we need to run configure on each platform when importing a new libgmp).

I think all of the .c code currently compiles, though I haven't yet diffed them with a regular gmp build to make sure that everything is compiling correctly.
I pushed the 5 commits to github just in case: https://github.com/mshal/gecko-dev/commits/bug-libgmp
Assignee: mshal → nobody
Priority: P1 → P5

Closing as invalid, given bug 1502797. We will be cleaning out the remaining GMP mentions in the build system for FF67.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
Attachment #9016726 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: