Bug 1803539 - [loong64][mips64] Include the missing headers for simulator. r=jandem Differential Revision: https://phabricator.services.mozilla.com/D163582

Bug 1803278 - Add a document describing the why/how of bytecode addition r=jandem Differential Revision: https://phabricator.services.mozilla.com/D163414

Bug 1801866: Inline String.fromCharCode when called with double inputs. r=jandem SunSpider's base64 calls `String.fromCharCode` with double inputs: ```js String.fromCharCode( (25 * Math.random()) + 97 ) ``` Supporting this case saves 7'860'000 calls to `String.fromCharCode` in JetStream's version of base64. Differential Revision: https://phabricator.services.mozilla.com/D162728

Bug 1801865: Supports out-of-bounds access for String.prototype.char{,Code}At. r=jandem After the patch for bug 1669942 there are still some non-inlined calls to `String.prototype.charAt` and `String.prototype.charCodeAt` in WBT benchmarks: acorn-wtb String.prototype.charCodeAt 1'150'000 jshint-wtb String.prototype.charAt 2'450'000 String.prototype.charCodeAt 200'000 uglify-js-wtb String.prototype.charAt 450'000 - "acorn-wtb" calls `String.prototype.charCodeAt` with an index above the string length. - "jshint-wtb" calls both `String.prototype.charCodeAt` and `String.prototype.charAt` with an index larger than the string length. - "uglify-js-wtb" calls `String.prototype.charAt` with a too large index and also negative values. CacheIR compilation can be easily modified to support out-of-bounds cases. But use separate MIR nodes for Warp transpilation: - `MCharCodeAt` is typed to return an Int32, whereas out-of-bounds accesses can return either an Int32 or NaN. - The `LoadStringCharResult` CacheIR op is transpiled using `MCharCodeAt` and `MFromCharCode`. But for out-of-bounds accesses we have to return the empty string. We can't easily modify the existing transpilation approach to return an empty string, so instead add a separate `MCharAtMaybeOutOfBounds` instruction. Differential Revision: https://phabricator.services.mozilla.com/D162727

Bug 1669942: Add CacheIR op to linearise strings for char-accesses. r=jandem We can't inline `String.prototype.charAt` and `String.prototype.charCodeAt` in a couple of JetStream tests because the input is a nested rope. Before this change, we can observe the following number of non-inlined calls to these functions: crypto String.prototype.charCodeAt 360'000 pdfjs String.prototype.charCodeAt 21'910'000 typescript String.prototype.charCodeAt 17'840'000 base64-SP String.prototype.charCodeAt 39'300'000 crypto-md5-SP String.prototype.charCodeAt 41'750'000 crypto-sha1-SP String.prototype.charCodeAt 30'180'000 acorn-wtb String.prototype.charCodeAt 3'370'000 jshint-wtb String.prototype.charAt 2'450'000 String.prototype.charCodeAt 200'000 uglify-js-wtb String.prototype.charAt 450'000 After this change, only the WBT sub-benchmarks still have non-inlined calls: acorn-wtb String.prototype.charCodeAt 1'150'000 jshint-wtb String.prototype.charAt 2'450'000 String.prototype.charCodeAt 200'000 uglify-js-wtb String.prototype.charAt 450'000 Differential Revision: https://phabricator.services.mozilla.com/D162726

Bug 1801864: Avoid unnecessary failure paths in DoubleNegationResult and DoubleIncDecResult. r=jandem Differential Revision: https://phabricator.services.mozilla.com/D162725

Bug 1802100: Add FrameIter::inPrologue r=jandem Differential Revision: https://phabricator.services.mozilla.com/D163409

Bug 1797486: Align visitOutOfLineStoreElementHole with CacheIR implementation r=jandem,nbp The existing implementation of StoreElementHole could handle indices > length, but we never actually used that path, because the corresponding code in `CacheIRCompiler::emitStoreDenseElementHole` only handles the index == initLength case (where we are adding one past the end). By aligning the Ion code more closely with the CacheIr implementation, we can remove some complexity. In particular, bailing out when index != length handles negative indices for free, which lets us remove the `needsNegativeIntCheck` code. Differential Revision: https://phabricator.services.mozilla.com/D163280

Bug 1219128 - Initialize Object and Function constructors when creating globals. r=jandem Object and Function prototype initialization is stateful, and mutate the global as it is initializing the content of the Global. Attempts at making this process transactional was not successful. Thus, `JSProto_Object` and `JSProto_Function` are now initialized as part of the Global creation. Failures to initialize the global might lead to have a Realm with a partially initialized global. Such realm appears to have a valid global using `hasLiveGlobal()`. When catching failures, such global might still be used despite being partially initialized. A new field `initializingGlobal_` is added to `Realm` to track whether the global is live or not. Failures to comply with this requirement would cause the garbage collector to reclaim the Realm and global in case of failure. This should be avoided during the initialization as the global is rooted by the `GlobalObject::new_` function. Differential Revision: https://phabricator.services.mozilla.com/D163016

Bug 1802497 - Part 5: Inline Number.prototype.toString when an explicit "base" argument is present. r=jandem Supporting this case saves about 2'300'000 VM calls in JetStream2 and 950'000 VM calls in Speedometer2. The new `Int32ToStringWithBaseResult` CacheIR op is transpiled into the two MIR instructions `MGuardInt32Range` and `MInt32ToStringWithBase`. In most cases the `base` argument is a constant, which enables to fold `MGuardInt32Range` away and also allows to make `MInt32ToStringWithBase` a non-guard instruction. Differential Revision: https://phabricator.services.mozilla.com/D163098

Bug 1802497 - Part 4: Add MacroAssembler method for int32 to string conversion with base. r=jandem A constant base argument is the most common case, so optimise this case even further. Differential Revision: https://phabricator.services.mozilla.com/D163097

Bug 1802497 - Part 3: Add MacroAssembler::mulhu32(). r=jandem Add unsigned, high-word, 32-bit multiplication in preparation for the next part. Differential Revision: https://phabricator.services.mozilla.com/D163096

Bug 1802497 - Part 2: Move ReciprocalMulConstants into a separate file. r=jandem This makes it easier to reuse this `struct` in part 4. Differential Revision: https://phabricator.services.mozilla.com/D163095

Bug 1802497 - Part 1: Add missing MOZ_EXPORT for ARM simulator functions. r=jandem The next part adds a new cpp-file, which changes unified bundles. Without this change we'll then get a "visibility does not match previous declaratio" error. Differential Revision: https://phabricator.services.mozilla.com/D163094

Bug 1802496: Inline the Number constructor when called with a string. r=jandem JetStream's "FlightPlanner" sub-benchmark hits this case 80'000 times. Differential Revision: https://phabricator.services.mozilla.com/D163093

Bug 1802495: Support more types when calling the String built-in constructor. r=jandem JetStream's "uglify-js-wtb" sub-benchmark has 130'000 calls to `String()` which weren't inlined because the input is `null`. Differential Revision: https://phabricator.services.mozilla.com/D163092

Bug 815255 - Part 5: Correct number bounds check in parseInt. r=jandem Only numbers whose absolute value is less than 1.0e-6 can't take the fast path, i.e. 1.0e-6 itself can still take the fast path. Differential Revision: https://phabricator.services.mozilla.com/D163091

Bug 815255 - Part 4: Inline Number.parseInt with Double input. r=jandem Supporting Double inputs allows to inline the 1'160'000 `parseInt` calls in JetStream's "string-unpack-code-SP" sub-benchmark. Differential Revision: https://phabricator.services.mozilla.com/D163090

Bug 815255 - Part 3: Inline Number.parseInt with radix=10. r=jandem The following JetStream benchmarks call `Number.parseInt`: - OfflineAssembler: 110'000 - FlightPlanner: 190'000 - Box2D: 7'130'000 - pdfjs: 1'200'000 - typescript: 10'000 - string-unpack-code-SP: 1'160'000 - acorn-wtb: 50'000 - babylon-wtb: 50'000 - chai-wtb: 50'000 - coffeescript-wtb: 50'000 - espree-wtb: 50'000 - jshint-wtb: 50'000 - lebab-wtb: 50'000 - prepack-wtb: 50'000 - uglify-js-wtb: 50'000 Supporting string and int32 inputs with radix=10 handles all calls to `Number.parseInt` in those benchmarks, except for: - OfflineAssembler: Calls `parseInt` with object inputs. - string-unpack-code-SP: Calls `parseInt` with double inputs. Differential Revision: https://phabricator.services.mozilla.com/D163089

Bug 815255 - Part 2: Add a VM-call entry point for Number.parseInt. r=jandem Split from the next part for easier review. Adds `js::NumberParseInt` which is going to be used in part 3. Differential Revision: https://phabricator.services.mozilla.com/D163088

Bug 815255 - Part 1: Add GuardSpecificInt32 CacheIR op. r=jandem Guard operation similar to the existing `GuardSpecificAtom` or `GuardSpecificSymbol`. Will be used in part 3. Differential Revision: https://phabricator.services.mozilla.com/D163087

Bug 1778510: Add a ShouldResistFingerprinting flag to JS RealmOptions r=jandem This will allow us to invoke the Timer Precision callback with this boolean. Differential Revision: https://phabricator.services.mozilla.com/D151283

Bug 1801108 - Improve debug printing of MIR. r=jandem. Debug printing of MIR is poor, which makes it difficult to debug the more complex Wasm->MIR translations, mostly because so much information is missing. This patch improves the basic printed structure and adds a framework by which we can incrementally add printing of MIR-node-specific fields in future. The following changes are made: * Printing of MIR expressions in nested style is removed. This is confusing in that casual reading of the output suggests that expressions are sometimes evaluated twice. This is removed and replaced with standard non-nested printing of (SSA) operands. * The result type of each MIR node is now printed before its name. This helps in debugging wasm 32-vs-64 bit code, for example. * Block IDs are now printed, so they can be referred to by branch insns. * A generic mechanism for printing extra, node-specific, fields has been introduced: overrideable method `MDefinition::getExtras`. By default this does nothing, but individual MIR classes can override it to provide any extra info they want. * For a few classes, `MDefinition::getExtras` has been filled in: for constants, comparisons, branch instructions, and fixed offsets in some wasm memory access insns. Differential Revision: https://phabricator.services.mozilla.com/D162547

Bug 1802497 - Part 5: Inline Number.prototype.toString when an explicit "base" argument is present. r=jandem Supporting this case saves about 2'300'000 VM calls in JetStream2 and 950'000 VM calls in Speedometer2. The new `Int32ToStringWithBaseResult` CacheIR op is transpiled into the two MIR instructions `MGuardInt32Range` and `MInt32ToStringWithBase`. In most cases the `base` argument is a constant, which enables to fold `MGuardInt32Range` away and also allows to make `MInt32ToStringWithBase` a non-guard instruction. Differential Revision: https://phabricator.services.mozilla.com/D163098

Bug 1802497 - Part 4: Add MacroAssembler method for int32 to string conversion with base. r=jandem A constant base argument is the most common case, so optimise this case even further. Differential Revision: https://phabricator.services.mozilla.com/D163097

Bug 1802497 - Part 3: Add MacroAssembler::mulhu32(). r=jandem Add unsigned, high-word, 32-bit multiplication in preparation for the next part. Differential Revision: https://phabricator.services.mozilla.com/D163096

Bug 1802497 - Part 2: Move ReciprocalMulConstants into a separate file. r=jandem This makes it easier to reuse this `struct` in part 4. Differential Revision: https://phabricator.services.mozilla.com/D163095

Bug 1802497 - Part 1: Add missing MOZ_EXPORT for ARM simulator functions. r=jandem The next part adds a new cpp-file, which changes unified bundles. Without this change we'll then get a "visibility does not match previous declaratio" error. Differential Revision: https://phabricator.services.mozilla.com/D163094

Bug 1802496: Inline the Number constructor when called with a string. r=jandem JetStream's "FlightPlanner" sub-benchmark hits this case 80'000 times. Differential Revision: https://phabricator.services.mozilla.com/D163093

Bug 1802495: Support more types when calling the String built-in constructor. r=jandem JetStream's "uglify-js-wtb" sub-benchmark has 130'000 calls to `String()` which weren't inlined because the input is `null`. Differential Revision: https://phabricator.services.mozilla.com/D163092

Bug 815255 - Part 5: Correct number bounds check in parseInt. r=jandem Only numbers whose absolute value is less than 1.0e-6 can't take the fast path, i.e. 1.0e-6 itself can still take the fast path. Differential Revision: https://phabricator.services.mozilla.com/D163091

Bug 815255 - Part 4: Inline Number.parseInt with Double input. r=jandem Supporting Double inputs allows to inline the 1'160'000 `parseInt` calls in JetStream's "string-unpack-code-SP" sub-benchmark. Differential Revision: https://phabricator.services.mozilla.com/D163090

Bug 815255 - Part 3: Inline Number.parseInt with radix=10. r=jandem The following JetStream benchmarks call `Number.parseInt`: - OfflineAssembler: 110'000 - FlightPlanner: 190'000 - Box2D: 7'130'000 - pdfjs: 1'200'000 - typescript: 10'000 - string-unpack-code-SP: 1'160'000 - acorn-wtb: 50'000 - babylon-wtb: 50'000 - chai-wtb: 50'000 - coffeescript-wtb: 50'000 - espree-wtb: 50'000 - jshint-wtb: 50'000 - lebab-wtb: 50'000 - prepack-wtb: 50'000 - uglify-js-wtb: 50'000 Supporting string and int32 inputs with radix=10 handles all calls to `Number.parseInt` in those benchmarks, except for: - OfflineAssembler: Calls `parseInt` with object inputs. - string-unpack-code-SP: Calls `parseInt` with double inputs. Differential Revision: https://phabricator.services.mozilla.com/D163089

Bug 815255 - Part 2: Add a VM-call entry point for Number.parseInt. r=jandem Split from the next part for easier review. Adds `js::NumberParseInt` which is going to be used in part 3. Differential Revision: https://phabricator.services.mozilla.com/D163088

Bug 815255 - Part 1: Add GuardSpecificInt32 CacheIR op. r=jandem Guard operation similar to the existing `GuardSpecificAtom` or `GuardSpecificSymbol`. Will be used in part 3. Differential Revision: https://phabricator.services.mozilla.com/D163087

Bug 1219128 - Initialize Object and Function constructors when creating globals. r=jandem Object and Function prototype initialization is stateful, and mutate the global as it is initializing the content of the Global. Attempts at making this process transactional was not successful. Thus, `JSProto_Object` and `JSProto_Function` are now initialized as part of the Global creation. Failures to initialize the global might lead to have a Realm with a partially initialized global. Such realm appears to have a valid global using `hasLiveGlobal()`. When catching failures, such global might still be used despite being partially initialized. A new field `initializingGlobal_` is added to `Realm` to track whether the global is live or not. Failures to comply with this requirement would cause the garbage collector to reclaim the Realm and global in case of failure. This should be avoided during the initialization as the global is rooted by the `GlobalObject::new_` function. Differential Revision: https://phabricator.services.mozilla.com/D163016

Bug 1800514: Don't unbox in GuardMultipleShapes r=jandem I was already staring at register allocation in this function, so it seemed like a reasonable time to fix this. Depends on D163154 Differential Revision: https://phabricator.services.mozilla.com/D163155

Bug 1671228: Part 8: Reduce register pressure in CloseIter r=jandem An xpcshell test on 32-bit windows ran out of registers because we folded a shapeguard in a CloseIter IC and the tag register of the input operand wasn't marked as available. Differential Revision: https://phabricator.services.mozilla.com/D163154

Bug 1671228: Part 7: Handle cross-compartment shapes r=jandem In the cross-compartment wrapper case, we can end up with shapes from a different compartment. The easiest fix to do is just not fold. Differential Revision: https://phabricator.services.mozilla.com/D163027

Bug 1671228: Part 6: Add tests r=jandem Differential Revision: https://phabricator.services.mozilla.com/D160933

Bug 1671228: Part 5: Try folding stubs before transitioning IC state r=jandem Differential Revision: https://phabricator.services.mozilla.com/D160932

Bug 1671228: Part 4: Add shapes to existing GuardMultipleShapes r=jandem Differential Revision: https://phabricator.services.mozilla.com/D160931

Bug 1671228: Part 3: Transpile GuardMultipleShapes r=jandem Differential Revision: https://phabricator.services.mozilla.com/D160930

Bug 1671228: Part 2: Implement TryFoldingStubs r=jandem Differential Revision: https://phabricator.services.mozilla.com/D160929

Bug 1671228: Part 1: Add GuardMultipleShapes r=jandem Differential Revision: https://phabricator.services.mozilla.com/D160928

Bug 1778510: Add a ShouldResistFingerprinting flag to JS RealmOptions r=jandem This will allow us to invoke the Timer Precision callback with this boolean. Differential Revision: https://phabricator.services.mozilla.com/D151283

Bug 1802731 - Fix accidental rename of regress-531682.js. r=jandem Differential Revision: https://phabricator.services.mozilla.com/D163222

Bug 1802479 - Don't set rval if JSContext::getPendingException fails r=jandem The problem here is that the ModuleEvaluate assumed that getPendingException would leave the output value as undefined if it failed, but that wasn't true. Differential Revision: https://phabricator.services.mozilla.com/D163205

Bug 1802308 - Make RegExpShared jitCode edges strong r=jandem The pre-barrier verifier is complaining, presumably because discarding JIT code removing one of these edges without marking the target. That happens because it's a WeakHeapPtr<> which doesn't have a pre-barrier. These don't need pre-barriers though because they have a read barrier instead. The verifier doesn't know this because the edge is traced like it's a strong edge in RegExpShared::traceChildren. The solution is just to make this a normal strong edge. Discarding JIT code usually happens before write barriers are enabled so we won't keep these around longer than normal. Differential Revision: https://phabricator.services.mozilla.com/D163015

Bug 1778510: Add a ShouldResistFingerprinting flag to JS RealmOptions r=jandem This will allow us to invoke the Timer Precision callback with this boolean. Differential Revision: https://phabricator.services.mozilla.com/D151283