Closed Bug 1612804 Opened 4 months ago Closed 2 months ago

Allow global initializers to reference functions with ref.func

Categories

(Core :: Javascript: WebAssembly, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla77
Tracking Status
firefox77 --- fixed

People

(Reporter: lth, Assigned: rhunt)

References

Details

Attachments

(8 files)

The spec hasn't completely gelled yet, see https://github.com/WebAssembly/reference-types/issues/76, but really we'll want to allow ref.func in global initializers (we don't) and we'll want functions that are referenced from ref.func in a global initializer to be marked as reffable as if they were in an element segment.

Summary: Allow global initializers to reference functions with ref.null → Allow global initializers to reference functions with ref.func
Priority: P3 → P2

This was my bad originally and has annoyed me since.

Assignee: nobody → rhunt
Status: NEW → ASSIGNED

With ref.func initializers, this process will become fallible and will need to
return a boolean value.

Depends on D68652

The problem here is that a ref.func global initializer needs to acquire an
exported function which is only available after an Instance object has been
created. However, we sometimes initialize global object cells before this for
exported globals defined in this module or imports satisfied with an immediate
value.

This commit changes EnsureExportedGlobalObject to only initialize the cell of
an import satisfied with an immediate value. Instance::init() is changed to
always initialize the cell of an indirect global. CreateExportObject is changed
to finally initialize the remaining global cells.

A later commit will clean up some of the redundancy in Instance::init().

Depends on D68653

This commit adds the decoding, validation, and initialization logic for ref.func
in globals.

There's an open issue about whether the function index needs to be declared in
an element segment. This commit assumes that this is not required. This may be
changed easily in the future.

A later commit will try to improve the InitExpr constructors as they have
become a little ambiguous with ref.func.

Depends on D68654

This commit adds a test for the various cases of initializing a global
with ref.func.

Depends on D68655

With the addition of ref.func, the approach of using an explicit constructor to
tag the kind of InitExpr has become a bit ambiguous. This commit tries to improve
the situation.

Depends on D68656

The case of GlobalKind::Variable has some redundancy that can be cleaned up.

Depends on D68657

Depends on D68658

Pushed by rhunt@eqrion.net:
https://hg.mozilla.org/integration/autoland/rev/fee56ab90f3a
Rename Instance::funcRef to Instance::refFunc. r=lth
https://hg.mozilla.org/integration/autoland/rev/5a5629e360b9
Move TlsData initialization out of Instance constructor. r=lth
https://hg.mozilla.org/integration/autoland/rev/27b629e8a145
Refactor initialization of global object cells. r=lth
https://hg.mozilla.org/integration/autoland/rev/7af3156de038
Add support for ref.func in global initializers. r=lth
https://hg.mozilla.org/integration/autoland/rev/88313d56af8e
Add test for ref.func in global initializers. r=lth
https://hg.mozilla.org/integration/autoland/rev/6c7a9af4b794
Clean up InitExpr constructors. r=lth
https://hg.mozilla.org/integration/autoland/rev/1fe26f008b09
Clean up Instance::init(). r=lth
https://hg.mozilla.org/integration/autoland/rev/c4fa7454aab6
Fix gc/nullref.js test. r=lth
You need to log in before you can comment on or make changes to this bug.