Bug 1767525 - Enable ShadowRealms test262 tests under flag r=jandem Differential Revision: https://phabricator.services.mozilla.com/D146238

Bug 1767525 - Implement (under a flag) ShadowRealm constructor and evaluate function. r=jandem Shell only, without HostInitializeShadowRealm, nor importValue Differential Revision: https://phabricator.services.mozilla.com/D146236

Bug 1767525 - Enable ShadowRealms test262 tests under flag r=jandem Differential Revision: https://phabricator.services.mozilla.com/D146238

Bug 1767525 - Implement (under a flag) ShadowRealm constructor and evaluate function. r=jandem Shell only, without HostInitializeShadowRealm, nor importValue Differential Revision: https://phabricator.services.mozilla.com/D146236

Bug 1773650: Move final yield to end of function r=jandem We generate very similar code when returning as when we fall off the end of a generator/async function. This patch unifies the two cases. We generate less bytecode this way. Also, OOMs or debugger-induced throws during the return will not be caught by try-catch blocks inside the function (although the outer reject catch will still see them; this is tested in `async/debugger-reject-after-fulfill.js`). It's a bit weird because AsyncResolve is infallible in the spec but not our implementation, but I think this approach is most consistent with the semantics in step 3 of (AsyncBlockStart)[https://tc39.es/ecma262/#sec-async-functions-abstract-operations-async-function-start] (called by EvaluateAsyncFunctionBody). The entire body is evaluated before we check `result.[[Type]]` to decide whether to resolve or reject the promise. Depends on D149469 Differential Revision: https://phabricator.services.mozilla.com/D149470

Bug 1773650: Move prepareIteratorResult into finishReturn r=jandem Wrapping the return value in an iterator in `finishReturn` instead of `emitReturn` makes it easier to unify code in the next patch. Differential Revision: https://phabricator.services.mozilla.com/D149469

Bug 1774249 - Fallibly generate unique ID for new prototypes in JSObject::setProtoUnchecked r=jandem Generate unique IDs for objects that are used as prototypes ahead of time, so we can do it fallibly. Differential Revision: https://phabricator.services.mozilla.com/D149356

Bug 1774145 - [loong64] Fix usage of undeclared identifiers. r=jandem Port D148487 and D148779 to loongarch64 platform. Differential Revision: https://phabricator.services.mozilla.com/D149200

Bug 1773843 - update jit-test README and describe how they are used in CI r=jandem DONTBUILD Differential Revision: https://phabricator.services.mozilla.com/D148985

Bug 1773368 - Remove deprecated typedefs for js::Scope. r=jandem Differential Revision: https://phabricator.services.mozilla.com/D148817

Bug 1773368 - Remove deprecated typedefs for js::Shape. r=jandem Differential Revision: https://phabricator.services.mozilla.com/D148816

Bug 1772282 - (part 2 of 3) Replace js/src/ds/SplayTree.h with an AvlTree.h and change all of SM's uses accordingly. r=jandem. This changes all 3 of SM's uses of js/src/ds/SplayTree.h to use js/src/ds/AvlTree.h. The new interface is almost identical to the old one, so the changes are mostly trivial: (0) js/src/jit/JitcodeMap.h: two comments referencing unknown "trees" have been amended. (1) js/src/ds/MemoryProtectionExceptionHandler.cpp: this uses a tree to record memory ranges that are protected (?). The only change is of the type of the tree. (2) BacktrackingAllocator.h: a minor use, to record ranges containing calls (`BacktrackingAllocator::callRanges`). Also just a change of type. It would be possible to use the AVL trees to merge the partially-redundant fields `::callRanges` and `::callRangesList`, but that is beyond the scope of this patch. (3) BacktrackingAllocator.h: the main use: changing `LiveRangeSet` to use an AvlTree. This is also just a renaming of the type. (3, more) struct `PrintLiveRange` has been removed. It was a workaround for the fact that the splay trees had no iteration facility. Its use, in BacktrackingAllocator::dumpAllocations, has been replaced by an AVL iterator. (3, more) Note that this change causes the allocator to produce different allocations. This is because the allocator depends on the actual tree layout, specifically which node is closest to the root when more than one node matches a query, and that's different for the two tree implementations. This behaviour manifests in BacktrackingAllocator::tryAllocateRegister, where register-use trees are queried: if (!rAlias.allocations.contains(range, &existing)) { continue; } This asks "does the tree contain a range that overlaps `range`?; if yes, return it in `existing`". If more than one range in the tree overlaps `range`, which one is written to `existing` is arbitrary. The code goes on to decide whether it's OK to evict the bundle containing existing based (in part) on `existing`s spill weight. This could be seen as a bug in the logic in that if `existing` has a low spill weight then it may choose to evict `existing`s bundle, even though some other range -- that wasn't returned -- has a higher spill weight. Hence it could incorrectly decide to evict a bundle that has a higher spill weight than the bundle for which allocation is attempted. The above analysis may be a misinterpretation of the logic. Multiple attempts to "fix" it were made, without success. In any case the resulting allocations are marginally better. See https://bugzilla.mozilla.org/show_bug.cgi?id=1772282#c2 Differential Revision: https://phabricator.services.mozilla.com/D148247

Bug 1773446 - [loong64] Add frame pointer to all arguments rectifier frames. r=jandem Port changes in bug 1772506 to loong64 backend. Differential Revision: https://phabricator.services.mozilla.com/D148752

Bug 1713579: Add testcase r=jandem Depends on D133129 Differential Revision: https://phabricator.services.mozilla.com/D133130

Bug 1729269: Add testcase r=jandem Differential Revision: https://phabricator.services.mozilla.com/D124998

Bug 1770509: Add ResumeMode::ResumeAfterCheckIsObject r=jandem If we throw an exception while building the stack frame in `BailoutIonToBaseline`, we will skip try/catch blocks in that frame. Throwing in `FinishBailoutToBaseline` ensures that we unwind correctly. Differential Revision: https://phabricator.services.mozilla.com/D148333

Bug 1770509: Update bailoutKind earlier r=jandem In the next patch, we want to change the bailout kind in BaselineStackBuilder. This patch sets the initial bailout kind earlier, so that we don't clobber the update. Depends on D147356 Differential Revision: https://phabricator.services.mozilla.com/D148332

Bug 1770509: Add tests r=jandem Differential Revision: https://phabricator.services.mozilla.com/D147356

Bug 1770509: Support return methods with nargs > 0 r=jandem We guard on the specific function/script, so nargs is constant for a particular IC stub. Generating a rectifier frame is overkill. The main use case for this is generators: `GeneratorReturn` takes one argument. Differential Revision: https://phabricator.services.mozilla.com/D147355

Bug 1770509: Support CompletionKind::Throw r=jandem The spec handles IteratorClose specially when the completion kind is 'throw' so that the original exception isn't overwritten by an exception that happens while closing the iterator. See https://tc39.es/ecma262/#sec-iteratorclose. Differential Revision: https://phabricator.services.mozilla.com/D147354

Bug 1770509: Transpile CloseIterScriptedResult r=jandem Differential Revision: https://phabricator.services.mozilla.com/D147352

Bug 1770509: Add CloseIterScriptedResult r=jandem This supports custom iterators with `return` methods. It is also necessary to support generators (which call the self-hosted `GeneratorReturn` function), although those won't work until a subsequent patch adds support for rectifier frames. Differential Revision: https://phabricator.services.mozilla.com/D147351

Bug 1770509: Support GuardFunctionScript in IonCacheIRCompiler r=jandem Differential Revision: https://phabricator.services.mozilla.com/D147350

Bug 1770509: Rename prepareVMCall to enterStubFrame r=jandem Entering a stub frame is the same whether we're doing a callVM or a callJit. This aligns better with baseline and simplifies the getter/setter code. At some point we could consider rewriting the Ion code to use AutoStubFrame. Differential Revision: https://phabricator.services.mozilla.com/D147349

Bug 1770509: Add LoadFixedSlot to CacheIR r=jandem We had LoadDynamicSlot, but not LoadFixedSlot. Differential Revision: https://phabricator.services.mozilla.com/D147348

Bug 1770509: Add Warp support r=jandem Differential Revision: https://phabricator.services.mozilla.com/D147347

Bug 1770509: Add CacheIR generator for CloseIter r=jandem `tryAttachNoReturnMethod` covers built-in collections (arrays, maps, and sets), and any custom iterator that doesn't have a return method. Differential Revision: https://phabricator.services.mozilla.com/D147346

Bug 1770509: Add baseline IC for CloseIter r=jandem Differential Revision: https://phabricator.services.mozilla.com/D147345

Bug 1770509: Add JSOp::CloseIter r=jandem This initial implementation doesn't handle throw completions. Support for those is added in a later patch. Differential Revision: https://phabricator.services.mozilla.com/D147344

Bug 1772123 - Ion's RA: reorder methods in BacktrackingAllocator.{cpp,h}. r=jandem. BacktrackingAllocator.cpp is a big, complex file. It contains the complete register allocation pipeline and has dozens of methods and functions. Unfortunately the organisation is poor, which obscures the overall structure makes it hard to follow: * often, no clear grouping of methods/functions into logical groups * inadequate group-heading comments, needed for top level navigation * inconsistencies in whether methods are defined before or after their use points * inconsistencies in the sequence of methods relative to flow in the allocator pipeline Any attempt to clean up the allocator first needs to address these structuring issues: * This patch makes no functional changes -- it merely reorders methods in BacktrackingAllocator.cpp and adds a handful of top-level section marker comments. The sequencing of methods is now definition-before-use. The top level group sequencing has been changed so as to match the actual flow of data through the allocation pipeline. * The contents of class BacktrackingAllocator in BacktrackingAllocator.h are rearranged to follow the .cpp changes. The rest of this file is unchanged. * minor change: BacktrackingAllocator::SpillWeightFromUsePolicy was a free method in the .h file. Has been moved to the .cpp file. * minor change: typedef LiveRangeVector is unused and has been removed. Differential Revision: https://phabricator.services.mozilla.com/D147926

Bug 1764451 - Handle ExtendedPrimitives properly in JS::Compartment::wrap() r=jandem Differential Revision: https://phabricator.services.mozilla.com/D143551

Bug 1426134 - Part 6: Remove no longer used framepointer-temp from LIonToWasmCallBase. r=jandem This code is no longer needed. Depends on D146708 Differential Revision: https://phabricator.services.mozilla.com/D146709

Bug 1426134 - Part 5: Remove frame pointer from allocatable register set. r=jandem Changes: - Replace `regs.take(BaselineFrameReg)` with `regs.takeUnchecked(...)`, because `BaselineFrameReg` is the frame pointer only on some platforms, which means it's no longer in the register set returned from `GeneralRegisterSet::All()`. - Remove `TakeJitRegisters` because the frame pointer is now always preserved. - Update `GenerateDirectCallFromJit` as instructed in the code comments. Drive-by change: - Remove `RegisterID::S0` and `RegisterID::S1`, because they are some old JSC-specific definitions. Instead add `RegisterID::fp`. Depends on D146707 Differential Revision: https://phabricator.services.mozilla.com/D146708

Bug 1426134 - Part 4: Disable GetElemSuper IC inlining on x86. r=jandem `LGetPropSuperCache` needs seven register, so it can't be used on x86. Depends on D146706 Differential Revision: https://phabricator.services.mozilla.com/D146707

Bug 1426134 - Part 3: Change IonCacheIRCompiler to work with one less temp register. r=jandem Use `AutoScratchRegisterMaybeOutputType` instead of `AutoScratchRegister`, so we need one less register. Change `IonCacheIRCompiler::emitCallNativeSetter()` to use `argUintN` as an additional scratch register on x86. Differential Revision: https://phabricator.services.mozilla.com/D146706

Bug 1426134 - Part 2: Change JitRealm::generateRegExpMatcherStub to work with one less register on x86. r=jandem We can't reuse the trick we've been using for `maybeTemp5` where we're reusing `lastIndex` as an additional temp register. (Also see bug 1480819.) Instead just save `regexp` and `lastIndex` on the stack and then use these register for `temp4` resp. `temp5`. This change also means `RegExpMatcherRaw` will now (again) always be called with a valid `lastIndex` argument. Differential Revision: https://phabricator.services.mozilla.com/D146705

Bug 1770268 - Add missing Zone-inl.h include in Shape.cpp. r=jandem Differential Revision: https://phabricator.services.mozilla.com/D146856

Bug 1770048: Improve self-hosted new_List r=jandem,tcampbell Differential Revision: https://phabricator.services.mozilla.com/D146760

Bug 1740263 - Block WASM code generation by CSP. r=lth,jandem I put the CSP check in the 5 WASM function that V8 also uses: https://source.chromium.org/search?q=IsWasmCodegenAllowed Is there somewhere else we might be generating WASM code? Some kind of caching etc. Differential Revision: https://phabricator.services.mozilla.com/D141978

Bug 1740263 - Move isRuntimeCodeGenEnabled to JSContext. r=jandem Differential Revision: https://phabricator.services.mozilla.com/D141977

Bug 1740263 - Block WASM code generation by CSP. r=lth,jandem I put the CSP check in the 5 WASM function that V8 also uses: https://source.chromium.org/search?q=IsWasmCodegenAllowed Is there somewhere else we might be generating WASM code? Some kind of caching etc. Differential Revision: https://phabricator.services.mozilla.com/D141978

Bug 1740263 - Move isRuntimeCodeGenEnabled to JSContext. r=jandem Differential Revision: https://phabricator.services.mozilla.com/D141977

Bug 1769723: Don't remove unbox instructions when folding tests. r=jandem Backed out changeset b3b4b19b2fec Differential Revision: https://phabricator.services.mozilla.com/D146594

Bug 1768660: Skip fewer values in buildExpressionStack r=jandem For the innermost frame of debugger mode bailouts, the current approach effectively uses an allow-list to decide which stack slots need to be recovered. This is fragile to any future bytecode changes that keep values alive on the expression stack. It's also unnecessary: if we just recover slots that are included in the snapshot, and skip slots that don't have allocations, everything works out. Differential Revision: https://phabricator.services.mozilla.com/D146525

Bug 1769220: Check test input for all phi-operands. r=jandem Differential Revision: https://phabricator.services.mozilla.com/D146286

Bug 1766656 - Take account of dynamic elements when swapping object r=jandem We need to copy nursery allocated elements into malloc memory when swapping a nursery obect into the tenured heap, and update memory accounting in a few places. The patch also fixes a bug in calculating how much of the nursery was tenured which came up during testing (we don't know how big proxy objects if they've been swpping into the nursery so assume the minimum size). Differential Revision: https://phabricator.services.mozilla.com/D145722

Bug 1768232 - Use a flag to indicate fixed elements rather than checking the elements pointer r=jandem This adds the ObjectElements::FIXED flag to indicate fixed elements and doesn't rely on the elements pointer. Differential Revision: https://phabricator.services.mozilla.com/D145960

Bug 1768346: Don't fold test block if the phi-operand doesn't match the initial test input. r=jandem Differential Revision: https://phabricator.services.mozilla.com/D145956

Bug 1767966 - Part 14: Merge both loops in FoldTests. r=jandem This improves the codegen for `if ((a < 10 && b < 20) || (c < 30 && d < 40)) { ... }`, where all inputs are int32 values. From: ``` cmp $0x0A, %edi setl %sil movzx %sil, %esi test %esi, %esi jz .L1 cmp $0x14, %ebp setl %sil movzx %sil, %esi set .L1 test %esi, %esi jnz .L2 cmp $0x1E, %edx jnl .L3 cmp $0x28, %ebx jnl .L3 ``` To: ``` cmp $0x0A, %ebp jnl .L1 cmp $0x14, %esi jl .L2 set .L1 cmp $0x1E, %edx jnl .L3 cmp $0x28, %ebx jnl .L3 ``` Differential Revision: https://phabricator.services.mozilla.com/D145601

Bug 1767966 - Part 13: Remove defunkt constant test condition code. r=jandem The two tests `!value->isConstant()` and `value->block() != block` in `BlockComputesConstant` have established these conditions: 1. `value` is a `MConstant` 2. `value` is part of `block` So when iterating over all iterations in `block`, the test `*iter != value || !iter->isGoto()` is always true. The code can be rewritten as: ``` if (*iter != value) { return false; } if (!iter->isGoto()) { return false; } ``` When `*iter` is equal to `value`, it can't be a `MGoto` instruction, because `value` is a `MConstant`. Instead the loop should watch out for any instructions which are neither `value` nor a `MGoto`, that means `||` should have been `&&`. Fixing this typo revealed two bugs, which were never noticed because the code was never actually run: 1. When we remove blocks which compute a constant, we may end up with unreachable blocks. This leads to errors in later passes. 2. When both arms of a test compute the same constant, the initial test will have a single predecessor. In that case we would need to replace the test instruction with a goto instruction. Because this optimisation never really worked and because GVN handles a similar case, let's just remove this code. Differential Revision: https://phabricator.services.mozilla.com/D145600