Closed Bug 1638295 Opened 4 years ago Closed 4 years ago

Support inlining Atomics functions for BigInt64/BigUint64

Categories

(Core :: JavaScript Engine: JIT, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
87 Branch
Tracking Status
firefox87 --- fixed

People

(Reporter: anba, Assigned: anba)

Details

Attachments

(12 files)

48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

Atomics functions aren't inlined for BigInt64/BigUint64 typed arrays.


(I don't plan to work on this feature, I just need to have a bug number for a comment in new code.)

Severity: -- → N/A
Priority: -- → P3

Move common code for converting operands into ConvertOperand and for unboxing
operands into UnboxOperand. Part 6 will also use ConvertOperand.

Assignee: nobody → andrebargull
Status: NEW → ASSIGNED

Small helper to abbreviate ScaleFromElemWidth(Scalar::byteSize(type)) to just
ScaleFromScalarType(type). Later patches will also use this new function.

Depends on D104162

This flag will be removed again at the end of this patch series. The flag
makes it possible to perform piecewise updates to allow BigInt inputs without
breaking the not yet updated functions.

Depends on D104164

For CacheIR we're using a VM call, because each platform has specific register
requirements we don't want to handle in CacheIR.

ARM32 and x86:
Reuse the existing WASM functions for MacroAssembler::atomicLoad64().

ARM64 and x64:
Call MacroAssembler::load64() with an explicit memory barrier.

Depends on D104165

For CacheIR we're using an ABI call, because each platform has specific register
requirements we don't want to handle in CacheIR.

ARM32 and x86:
Reuse the existing WASM functions for MacroAssembler::atomicStore64().

x86-only:
We're running out of registers, so we have to reuse edx as an additional temp
register.

ARM64 and x64:
Call MacroAssembler::store64() with an explicit memory barrier.

Depends on D104166

Similar to the previous parts, CacheIR always calls into the VM and only Warp
performs the operation in inline assembly.

TypePolicy.cpp:

  • Add TruncateToInt32OrToBigIntPolicy similar to the existing TruncateToInt32Policy.
  • TruncateToInt32Policy will be removed at the end of this patch series.

CodeGenerator.cpp:
Add createBigIntOutOfLine() so we can call it from "CodeGenerator-x86.cpp".

x86:
The lack of free registers makes it necessary to use the stack more often to
temporarily save some registers.

Depends on D104167

Updates CacheIR for AtomicReadModifyWrite operations to support BigInt results.

Similar to part 3, add a temporary supportBigInt flag which will later be
removed again.

Depends on D104170

The type policy is no longer used.

Depends on D104173

Atomic fetch operations are effectful, which means they're attached to a resume
point. And because a resume point counts as a use, the "forEffect" optimisation
was never triggered. This is a regression from bug 1146364.

This optimisation is especially useful for atomic operations on BigInts, because
it allows us to omit the allocation of the result BigInt.

WarpCacheIRTranspiler::emitAtomicsBinaryOp() pushes undefined on the stack
when the "forEffect" optimisation is used, which should be okay because the
result is directly popped from the stack again.

ARM64:
Add the implementation for LAtomicTypedArrayElementBinopForEffect which is now
required to be present.

Depends on D104174

Pushed by archaeopteryx@coole-files.de: https://hg.mozilla.org/integration/autoland/rev/5a0a182e23a4 Part 1: Reduce code duplication when converting or unboxing operands in type policies. r=jandem https://hg.mozilla.org/integration/autoland/rev/5945dd7a044b Part 2: Add ScaleFromScalarType to convert from Scalar::Type to Scale. r=jandem https://hg.mozilla.org/integration/autoland/rev/ec6924fb01b0 Part 3: Add a temporary flag to AtomicsMeetsPreconditions to enable BigInt for some operations. r=jandem https://hg.mozilla.org/integration/autoland/rev/ca1ee10645a8 Part 4: Inline Atomics.load with BigInt64 typed arrays. r=jandem https://hg.mozilla.org/integration/autoland/rev/383b15c21c8c Part 5: Inline Atomics.store with BigInt64 typed arrays. r=jandem https://hg.mozilla.org/integration/autoland/rev/3e2bc51738df Part 6: Inline Atomics.compareExchange with BigInt64 typed arrays. r=jandem https://hg.mozilla.org/integration/autoland/rev/139d52d305d7 Part 7: Prepare AtomicReadModifyWrite operations for BigInt support. r=jandem https://hg.mozilla.org/integration/autoland/rev/69c02b1a38bc Part 8: Inline Atomics.exchange with BigInt64 typed arrays. r=jandem https://hg.mozilla.org/integration/autoland/rev/8f83f6869c7c Part 9: Inline Atomics.{add,and,or,sub,xor} with BigInt64 typed arrays. r=jandem https://hg.mozilla.org/integration/autoland/rev/687ba6d36005 Part 10: Remove TruncateToInt32Policy. r=jandem https://hg.mozilla.org/integration/autoland/rev/c42ecf3fdcfe Part 11: Re-enable "forEffect" optimisation for Atomics fetch operations. r=jandem

Inline Atomics.load, Atomics.store, Atomics.compareExchange,
Atomics.exchange and Atomics.{add,and,or,sub,xor}.

Pushed by jdemooij@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3b0eba2b50f9 [MIPS] Support inlining Atomics functions for BigInt64/BigUint64.r=lth
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: