- 25 Feb, 2021 2 commits
-
-
Liu Yu authored
Port: 96a0677a Bug: v8:11477 Change-Id: I438a5b833a9838ffa53d30785cf627f75997d7fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2719402 Auto-Submit: Liu yu <liuyu@loongson.cn> Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#73037}
-
Manos Koukoutos authored
Calling CheckForException through the BUILD macro for almost every invocation of WasmGraphBuilder from graph-builder-interface created multiple issues: - It generated an invalid graph with GetExceptionValues, resulting in us having to hack CallBuiltin(). - It will generate multiple problems with wasm-gc operations. - It needlessly slowed down compilation. Changes: - Remove BUILD macro, call CheckForException directly only for function calls and throws. - Split CheckForException into a fast inline path and a slow non-inline one. - Move BUILD's DCHECK into CHECK_INTERFACE. - Add an early exit to Decode(). - Since we do not need the hack anymore, implement CallBuiltin properly. Change-Id: I38e3c73e0af80894584ce37e2f3bfc90111ac54f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2717304 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73036}
-
- 24 Feb, 2021 38 commits
-
-
Ng Zhi An authored
Bug: v8:11086 Change-Id: I214ebd0cc7c3b0379fcd6bc78e131fccf7bfe631 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707776Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#73035}
-
Francis McCabe authored
This reverts commit ae153904. Reason for revert: link error in https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20full%20debug/16047/overview Original change's description: > [dict-proto] C++ implementation of SwissNameDictionary, pt. 6 > > This CL is part of a series that adds the C++ implementation of > SwissNameDictionary, a deterministic property backing store based on > Swiss Tables. > > This CL adds the Add, DeleteEntry, Rehash, and Shrink operations, as > well as some helpers required by those. > > Bug: v8:11388 > Change-Id: I81a181e99e679095c2acc877a293e81b6a581db4 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715192 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Commit-Queue: Frank Emrich <emrich@google.com> > Cr-Commit-Position: refs/heads/master@{#73020} Bug: v8:11388 Change-Id: I7c83ddfab6055b992f1580e03aae0da31d83ba63 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718662 Auto-Submit: Francis McCabe <fgm@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#73034}
-
Junliang Yan authored
Change-Id: I60683dd37939d330169e3879982a6ac9ca7694a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718230Reviewed-by: Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#73033}
-
Ng Zhi An authored
Accidentally omitted this in a previous change https://crrev.com/c/2686013. Extract code sequence into macro-assembler for sharing between Liftoff and TurboFan. Bug: v8:11348 Change-Id: Ia4e9d1e0dc7a7f3a1a21ff1e1745923a847328cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707773Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#73032}
-
Milad Fa authored
Change-Id: I0723febc3e0d18e68bb629ccd2548108aa662bf5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718472Reviewed-by: Junliang Yan <junyan@redhat.com> Reviewed-by: Milad Fa <mfarazma@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#73031}
-
Ng Zhi An authored
arm64 is straightforward, for arm we extract the code sequence into a macro-assembler function. Bug: v8:11416 Change-Id: I6dddcee700c497e29f1ee8094cd81adfb1df2f4e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707769Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#73030}
-
Zhi An Ng authored
This reverts commit ea818f07. Reason for revert: Test failure in Linux64 UBSan https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/15251/overview Original change's description: > cppgc: Fix testing APIs that enable garbage collection > > The APIs require that the CppHeap is moved into a permanently detached > state that moves the heap out of a no-gc scope. > > Bug: chromium:1056170 > Change-Id: I1fc08451b3fdfaa4cfe58e6a1ddbe5dbed7efe5c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718146 > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73025} Bug: chromium:1056170 Change-Id: Id00cb18274cbe7d255e7e95bd9e8e4dbc4b0c6e7 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718658 Auto-Submit: Zhi An Ng <zhin@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#73029}
-
Ng Zhi An authored
Bug: v8:11086 Change-Id: I67f7aaeb1151b14678d6257a195efd19c86c5fbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707775Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#73028}
-
Milad Fa authored
We also define the getters and setters for the newly defined registers and their lanes. Change-Id: I1da9caed5f2f2d9ce79f43d9f70dc994f2200bff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718468Reviewed-by: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#73027}
-
Junliang Yan authored
Change-Id: Idc8d4e8d99b1a1e82af4c06940c3ca19f103d09f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718470Reviewed-by: Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#73026}
-
Michael Lippautz authored
The APIs require that the CppHeap is moved into a permanently detached state that moves the heap out of a no-gc scope. Bug: chromium:1056170 Change-Id: I1fc08451b3fdfaa4cfe58e6a1ddbe5dbed7efe5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718146 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#73025}
-
Austin Eng authored
- Add a CFunctionBuilder interface to allow adding modifier flags to argument types. This will be used to support IDL attributes like [EnforceRange], [Clamp], and [AllowShared]. This CL adds only the interface, but the actual modifier flags do not exist yet as they would not be implemented. - Remove the internals of the old CFunction type inference and implement it on top of CFunctionBuilder. Bug: chromium:1052746 Change-Id: I09a7cba07105097517a8426a8eeb891393883ac6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686686Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Austin Eng <enga@chromium.org> Cr-Commit-Position: refs/heads/master@{#73024}
-
Omer Katz authored
Two threads might get the same PersistentNode because the BasicCrossThreadPersistent ctor wasn't taking a lock. Then if one thread frees the node and the other initalizes it or updates its owner, we get some random object in our free list of PersistentNodes. I debug a crash in Assign(Unsafe) and Clear where the PersistentNode seemed to be allocated on stack. Empirically, adding this guard resolved it. I can't confirm in the code that the scenario above is what was happening. Drive-by: adding a few DCHECKs. Bug: chromium:1056170 Change-Id: I37d8ed5bb942a124c98d7524b7f04fe8ccb2aefd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718144 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#73023}
-
Igor Sheludko authored
... to match what the builtin expects. Bug: v8:11499, v8:11429 Change-Id: I6e784f6c5109f8d92446e98b8abb7274d5a166a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718151 Commit-Queue: Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73022}
-
Milad Fa authored
Change-Id: I9b40a06bdfd3b38aa25d05f2c3b8605f480b1236 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718465Reviewed-by: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#73021}
-
Frank Emrich authored
This CL is part of a series that adds the C++ implementation of SwissNameDictionary, a deterministic property backing store based on Swiss Tables. This CL adds the Add, DeleteEntry, Rehash, and Shrink operations, as well as some helpers required by those. Bug: v8:11388 Change-Id: I81a181e99e679095c2acc877a293e81b6a581db4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715192Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Frank Emrich <emrich@google.com> Cr-Commit-Position: refs/heads/master@{#73020}
-
Thibaud Michaud authored
This was staged through a back-merge in v8.9. Also stage it for the upcoming v9.0 release. R=clemensb@chromium.org Bug: v8:8091 Change-Id: Ib9e8c33ca258c8b9e407fbcca5db9f0227b558b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718150Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#73019}
-
Seth Brenith authored
Currently, some ScopeInfo fields are defined as indexed fields with a length of either one or zero, because the field might be present or it might not. Based on comments in https://crrev.com/c/v8/v8/+/2601880 , this strategy is not sustainable and we need a better way to represent optional fields so that we don't have to pass zero when accessing their only element. This change is a proposal to fix that problem. Syntax: I'm proposing using a question mark because TypeScript does, and Torque syntax looks somewhat like TypeScript. I don't feel strongly about this though, and I'm open to other suggestions. field_name?[condition_expression]: FieldType; Internal Torque compiler representation: Internally, I've updated the Torque compiler to still treat these fields as indexed, but with an extra flag saying they're optional. When getting a LocationReference for a field access expression on an optional field, Torque produces a Slice like it would for any other indexed field and subsequently calls AtIndex(0) to get a Reference. AtIndex can crash the process if the index is out of bounds (which is good), so some other parts of the Torque compiler need minor adjustments so that it doesn't take references to optional fields unless it actually needs them. Initialization: This proposal doesn't include any changes to initialization logic, so an optional field can still be initialized using '...' and an iterator. Perhaps we could introduce an Optional<T> struct for prettier initialization in a future change. Bug: v8:7793 Change-Id: I37649495f4c259e685261f53e4cf2859da66a31f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706306 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73018}
-
Junliang Yan authored
Port 96a0677a The precise type is only used for validation. For code generation, knowing the kind is more than enough. Hence, only store and pass the ValueKind in Liftoff, and not the full ValueType. Change-Id: Ia3a07df393b2f93d8d8c51bd41b3bd3a3bd6c6fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715987Reviewed-by: Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#73017}
-
Thibaud Michaud authored
This reverts commit 1db61fb3. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/34083/overview Original change's description: > [wasm][eh] Stage exception handling > > This was staged through a back-merge in v8.9. Also stage it for the > upcoming v9.0 release. > > R=ahaas@chromium.org > > Bug: v8:8091 > Change-Id: Ie9e6d25bbc5d428e5c9128345209f95f2078b733 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715524 > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73013} Bug: v8:8091 Change-Id: I18b9706e8aab4883a3d3c120a6cd06e7232aecf7 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718148 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#73016}
-
Seth Brenith authored
This is a partial reland of https://crrev.com/c/v8/v8/+/2601880 . I think it makes more sense to list ScopeInfos under "(system)" in the dev tools, like most other V8 internal types. Change-Id: If85f869e805d7c374fc7584a79155bb4f400e4b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707249Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73015}
-
Manos Koukoutos authored
Some helpers that depend on a MachineGraph or WasmGraphAssembler are moved into WasmGraphAssembler. Also, GetAsmJsOOBValue is inlined. Change-Id: I8760218cdba1e0f1564cdb044def4a68b348eac3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2717303Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#73014}
-
Thibaud Michaud authored
This was staged through a back-merge in v8.9. Also stage it for the upcoming v9.0 release. R=ahaas@chromium.org Bug: v8:8091 Change-Id: Ie9e6d25bbc5d428e5c9128345209f95f2078b733 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715524 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#73013}
-
Mike Stanton authored
Perform relaxed reads/writes on the builtin index. Bug: v8:11478, v8:7790 Change-Id: I488fd30e6635f39bb46440e9d5230ab311825e7d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716290Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#73012}
-
Milad Fa authored
Port 31aab838 Original Commit Message: Extract code sequence into macro-assembler for sharing between Liftoff and TurboFan. Relax the register aliasing requirements (remove the DCHECKS), this will not affect codegen for TurboFan since the instruction selector already sets the correct restrictions, but makes it more flexible for use in Liftoff. R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: I729095aae0412fce70ec97a1d7c5f27d32b1a932 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718143Reviewed-by: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#73011}
-
Michael Lippautz authored
Bug: chromium:1056170 Change-Id: Ib2b2788c7d59f873583e26a0716bacbf16766c93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716291Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#73010}
-
Manos Koukoutos authored
Design doc: https://docs.google.com/document/d/1AsUCqslMUB6fLdnGq0ZoPk2kn50jIJAWAL77lKXXP5g/ Currently, wasm loop unrolling is disabled by default. We intend to further investigate its compilation time cost and running time benefits before enabling it. Additional changes: - Introduce LoopFinder::FindUnnestedLoopFromHeader() as a lightweight loop analysis. - Move EliminateLoopExit into LoopPeeling and expose it. - Introduce loop_info_ field into WasmGraphBuildingInterface, fill it up in Loop(). - Break after encountering the first loop in BuildNestedLoopExits. - Introduce struct WasmLoopInfo. A WasmLoopInfo vector is instantiated in ExecuteTurbofanWasmCompilation, passed to BuildGraphForWasmFunction to be filled up by WasmGraphBuildingInterface, and then passed to GenerateCodeForWasmFunction to be used in WasmLoopUnrollingPhase. - Introduce WasmLoopUnrollingPhase and insert it into the wasm compilation pipeline. - Fix an issue where exception values were not wrapped in WasmGraphBuilderInterface. - Update --wasm-loop-unrolling flag description. Bug: v8:11298 Change-Id: I4b57cf2ea8520931f60769f843ffd57b3ca6399b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697349 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#73009}
-
Kim-Anh Tran authored
This adds a re-compilation of top level functions in getPossibleBreakpoints if no candidates could be found. This step is necessary as the GC may remove SharedFunctionInfo about top-level functions. Bug: chromium:1137141 Change-Id: I8830438d78751ba318d65f43d790ee98f306a57e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696154Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#73008}
-
Junliang Yan authored
Change-Id: I60b9cb6e0f7552fbdc35b62b6b379c8ac5f203e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716323Reviewed-by: Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#73007}
-
Jakob Gruber authored
The available constants are now: JSObject { kMaxElementCount = kMaxUInt32, kMaxElementIndex = kMaxElementCount - 1, } JSArray { kMaxArrayLength = JSObject::kMaxElementCount, kMaxArrayIndex = JSObject::kMaxElementIndex, } I also updated the codebase to use the new constants. Change-Id: I3142f9ff9627c9acb1d4493729b490150fdcdf50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712755Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#73006}
-
Georg Neis authored
It had essentially become a synonym for BytecodeArrayAccessor. This removes the BytecodeArrayIterator class and renames BytecodeArrayAccessor to BytecodeArrayIterator. Change-Id: I79cf8574f3c8804822f90c8f921c17ca7ab85f48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715523 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#73005}
-
Gus Caplan authored
Bug: v8:10855 Change-Id: I0f28603421ba36176d177bfcc25f18a26a097c29 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716062Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Gus Caplan <snek@chromium.org> Cr-Commit-Position: refs/heads/master@{#73004}
-
Leszek Swirski authored
We were using CmpInstanceType instead of CmpObjectType in some places, which meant that we were reading the value at the instance type field offset within objects directly, rather than first loading their map and reading the instance type there. Bug: chromium:1180434 Change-Id: I4771b4f8f9a32bdc35944c6e6cd30c54e4ac8b6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716292 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73003}
-
Sathya Gunasekaran authored
Bug: v8:11321 Change-Id: Ica350e9a613d6dddb17569ce5b2df072ceb2c050 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2717156 Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#73002}
-
Manos Koukoutos authored
These functions are defined in WasmGraphBuilder, so we do not need to invoke them in mcgraph() or gasm_. Change-Id: Ibd97add56d22bff7eb99addd78bf599057b21041 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2717302Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#73001}
-
Omer Katz authored
Assert that the lock is help whenever AssignUnsafe is called. LazyMutex::AssertHeld resolves to a DCHECK so this should not regress production performance (other than the call itself that might not be inlined). Bug: chromium:1056170 Change-Id: Ic2005d180e6960c24dff7743aa3e0d5e57a63d80 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716286Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#73000}
-
Georg Neis authored
Bug: v8:7790 Change-Id: Iae4374e352aea0169d4fe1eba5d825c16efe3940 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715198 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72999}
-
Emanuel Ziegler authored
When calling new WebAssembly.Table, the returned error message refers accidentally to the WebAssembly.Module() constructor. There will be a corresponding Chromium CL fixing expected error messages in WPTs. R=ahaas@chromium.org Bug: v8:11356 Change-Id: I57f5e071d5c542615523345283d7c3613fb7a616 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2663155Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/master@{#72998}
-