- 13 Mar, 2020 20 commits
-
-
Ng Zhi An authored
Add a bunch of i8x16, i16x8, i32x4 binops. Bug: v8:10180 Change-Id: I576dbb605f1769ace2c832988c5205eaefc4476a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101937Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66709}
-
Andreas Haas authored
R=clemensb@chromium.org Bug: v8:10281 Change-Id: I33ca74a1536f4a99478aa1ee42dd7c7a46980f6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100999 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66708}
-
Andreas Haas authored
This CL extracts a function which reads from a buffer and additionally increments an offset for the next read. R=clemensb@chromium.org Bug: v8:10281, v8:10155 Change-Id: Id8d79130cde17053d701d2508e40cba993471e55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101001 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Georg Neis authored
Change-Id: Iaf7f83cc157a6f6680da8933560347f7f3503d56 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098736Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66706}
-
Milad Farazmand authored
Port 11da29a7 R=fanchen.kong@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I5ea7bc62dcbd2411b84c5b9bfbe1fb6cdf0ee592 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102769Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66705}
-
Thibaud Michaud authored
R=clemensb@chromium.org Bug: v8:10321 Change-Id: Ia082b842de8947ead3931943b3bc05903a0f9e29 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101002Reviewed-by:
-
Andreas Haas authored
Doing the bounds check in C++ has the advantage that we generate less code, and that TurboFan graphs get smaller. Additionally it will make code generation from Liftoff easier. There is not really a downside: We already called C++ anyways to do the actual memory.fill operation. R=clemensb@chromium.org Bug: v8:10281 Change-Id: If4e36d45a3fd1c4c0fef9137d37097a012e7a409 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100991 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Jakob Kummerow authored
to properly choose named or indexed mode Bug: chromium:1059738 Change-Id: Icd086fee31079f52770742afa54fc946acb1fd81 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101005 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66702}
-
Jakob Kummerow authored
SignatureHelper::kMarker needs an explicit instantiation after f3b4167f. Change-Id: Ia5a0696a576a2c59bea262359058bd63eb3c8426 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101004 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66701}
-
Andreas Haas authored
This CL adds memory masking to our implementation of memory.copy and memory.init when spectre mitigations are enabled. R=clemensb@chromium.org Bug: v8:10281 Change-Id: I8722fa7ab244f339d859d5479eceede85dbbd08c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100990 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Zhao Jiazhong authored
Port f3b4167f https://crrev.com/c/2091471 Original Commit Message: In preparation for adding reference types, which need an additional parameter to indicate the referenced type. Change-Id: I1b66bffea3ac2637886673476c8f7d62150b33a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100695 Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66699}
-
Zhao Jiazhong authored
Port 11da29a7 https://crrev.com/c/2086706 Change-Id: I1f9227bfc12a0d1a60aa6d34f41a3a3903a5a24f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100703Reviewed-by:
-
Thibaud Michaud authored
Flood functions with breakpoints to prepare them for stepping. With a small modification to the runtime function, this already implements a basic step over functionality. We still cannot resume, step in or step out (including stepping over a return instruction). R=clemensb@chromium.org Bug: v8:10321 Change-Id: Ia4a6335d24c1a511c2f1fc9b48d728f327b3df56 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098732Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
-
Andreas Haas authored
In debug builds of Liftoff, the opcode of the next instruction is printed as a code comment. For multi-byte opcodes, all but the first byte have to be extracted explicitly from the wasm code in the {NextInstruction} function. The bounds check for this extraction was missing. R=clemensb@chromium.org Bug: chromium:1061304 Change-Id: I16a05d54e50506c1387970ad84082d7e76108fc0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100996Reviewed-by: -
Clemens Backes authored
The {TYPE_CHECK} macro used an ancient pattern to check for assignability, by assigning to a static_casted nullptrs of the respective types. C++11 introduced standard library helpers to express this more naturally. The most direct translation would have been to use {std::is_assignable} or {std::is_convertible} on the pointer types, but in most cases we can be even more strict and force one type to be a proper subtype of the other. The only exception is {ReturnValue}, which allows to assign anything if it's void. R=ulan@chromium.org Bug: v8:10155 Change-Id: I41c1103e0206514c8700c47a0bf107ad704cfc47 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093497Reviewed-by:Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66695}
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: If1293fd4ec36f56e459c79ee6ed4fdc466bbded1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2086706Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Cr-Commit-Position: refs/heads/master@{#66694}
-
Joyee Cheung authored
Address a TODO in tests Bug: v8:8330 Change-Id: I2b8d5cef488ca56331448dcb11fad7a00f19d501 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095638Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#66693}
-
Ng Zhi An authored
s128.store should be in the list for generating kStmt, not kWasmS128. No regression test added because the generated JS file is not helpful for this bug - the failed assertion is in the fuzzer, not the engine. Bug: chromium:1061049 Change-Id: I44092fa10c57aeeb34f1c6c5a7d655def31a7363 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101927Reviewed-by:
-
Deepti Gandluri authored
Bug: v8:10309 Change-Id: Ib0ad8f936d0229129315e8e48e54fa500fd40cd5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101701Reviewed-by:
Ben Smith <binji@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#66691}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/8a766f0..cdcb92e Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/1a8a3a7..4164a30 Rolling v8/buildtools/linux64: git_revision:fd3d768bcfd44a8d9639fe278581bd9851d0ce3a..git_revision:9499562d94bf142f43d03622492e67b217461f67 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/786ed18..40469eb Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/1ee78cd..595eb19 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/ca7cd9b..8bf2cd1 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I5764ccc04cbd265b76935062b1f67730fa6bf29c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100533Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#66690}
-
- 12 Mar, 2020 19 commits
-
-
Milad Farazmand authored
Port f3b4167f Original Commit Message: In preparation for adding reference types, which need an additional parameter to indicate the referenced type. R=jkummerow@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ia6d933611440096247dda159846f6c119f5167d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101607Reviewed-by:
-
Seth Brenith authored
This change is based on a discussion from https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696 wherein Tobias suggested moving the folding away of ==0 operations out of the platform-specific instruction selectors and into the MachineOperatorReducer. I noticed that CommonOperatorReducer already handles some very similar cases, so I have tried putting the ==0 folding into CommonOperatorReducer instead. I'm happy to move it into MachineOperatorReducer if that's better; I still don't have a very good understanding of how roles are separated among reducers. Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
-
Jakob Kummerow authored
In preparation for adding reference types, which need an additional parameter to indicate the referenced type. Bug: v8:7748 Change-Id: If4023f3d9c7f42ed603b69c43356d2e8b81a0daa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091471 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Andreas Haas authored
On Windows in an asan build we have to reset the thread-in-wasm flag in the memory_init_wrapper, memory_copy_wrapper, and memory_fill_wrapper. Accidentally I removed this code for the memory_init_wrapper and the memory_copy_wrapper recently. This CL introduces the code again. R=clemensb@chromium.org Bug: v8:10281 Change-Id: If46def5cd64ac8cbff9b86108189462717961edd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098737Reviewed-by:
-
Andreas Haas authored
x64's cmpxchgl instruction does not zero-extend the register. The stale high word caused the difference in the results of the interpreter and Liftoff/TurboFan. R=clemensb@chromium.org CC=zhin@chromium.org Bug: chromium:1059529 Change-Id: I0fd440bee26e25b90b29533cfa9151e4d87754e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098726 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66685}
-
Georg Neis authored
... such that we have only a single representation for special constants such as undefined, namely the corresponding bitset. With this CL the following property holds: t1.IsSingleton() /\ t2.Is(t1) => t1.Is(t2) Also clean up the Type interface and improve test coverage a little. Change-Id: I074e20047c92e2c8215c2d438f2627f4ffdbc409 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096631 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: -
Mike Stanton authored
In typed lowering, if our target is a CheckClosure or a CreateClosure node, we can extract a SharedFunctionInfo from the opcodes parameters in order to make calls a bit more efficient. Change-Id: Ib06dea2e8505bfeb984c4cefd5ad1bed0defa5f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087402 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
Andreas Haas authored
R=clemensb@chromium.org Bug: v8:10281 Change-Id: I321e65f42fd68a3451b49881b04bfb38dd7ff8ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091469 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Steve Blackburn authored
Bug: v8:9533 Change-Id: Ida93a4a6dd5d25e78bb2bc113b869bc01cd7a650 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043808 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Georg Neis authored
Change-Id: I0dc2a198c412723933cb1bc259423ff241612fcc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098731 Commit-Queue: Georg Neis <neis@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#66680}
-
Leszek Swirski authored
The interpreter's finalization was accidentally double-counting compile finalizations, which manifested as a Compile count increase. As a side effect, this would also miscount off-thread finalizations as main-thread finalizations -- not a problem yet, but would be one in the future. Bug: chromium:1011762 Bug: chromium:1060927 Change-Id: I37232bbd46c8cba80c0b413638f43d83d5313e70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098727 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Some Scope methods were unnecessarily taking a ParseInfo, or using only a single field from it. We can avoid passing around ParseInfo in these cases, which will make splitting/removing it easier in the future. Bug: v8:10314 Change-Id: I5c60783d27581c4f7d8c709314bbfc72ac5bd0f6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096630 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Zhao Jiazhong authored
Port 485e66ba https://crrev.com/c/2094198 Change-Id: I4e3ce2a70f2ccf4e95b0fa69834522d988e00f9b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097895Reviewed-by:
-
Iain Ireland authored
This is a grab-bag of small compatibility fixes to make it easier to import irregexp into SpiderMonkey. For changes where the commit message was longer than the change itself, it didn't seem worth opening a separate review. [regexp] Use uc16 in FilterOneByte SpiderMonkey uses char16_t instead of uint16_t for its two-byte strings. (This matches ICU. It looks like V8 considered making the same change, but decided against it: see https://bugs.chromium.org/p/v8/issues/detail?id=6487.) Fortunately, irregexp is careful about only using uc16, so SpiderMonkey can just define uc16 = char16_t and *almost* everything works out. This patch fixes the single place in irregexp where that is not true. [regexp] Remove unreachable return The return statement at the end of RegExpParser::ParseClassCharacterEscape is unreachable, because every branch of the switch returns. This triggered static analysis errors in SpiderMonkey. [regexp] Remove trivial assertion The assertion in BytecodeSequenceNode::ArgumentMapping cannot fail, because size_t is an unsigned type. This triggered static analysis warnings in SpiderMonkey. [regexp] Make RegExpStack constructor public In V8, the RegExpStack's private constructor is called from Isolate, which is a friend class. In SpiderMonkey, we use a wrapper around new to control where memory is allocated, so we need the RegExpStack constructor to be visible outside of Isolate. [regexp] Refactor Isolate::IncreaseTotalRegexpCodeGenerated The call-site of Isolate::IncreaseTotalRegexpCodeGenerated is the only place inside irregexp where HeapObject::Size is called. SpiderMonkey's heap-allocated objects live in arenas, and don't have a standardized way of finding the size. In this particular case it would be safe to hardcode a size of 0, but leaving HeapObject::Size undefined will ensure that SpiderMonkey doesn't silently do the wrong thing if somebody in V8 adds a new, more meaningful call to HeapObject::Size. R=jgruber@chromium.org Bug: v8:10303 Change-Id: I5b81e1a261fec8c85a63f71f34cd12d68f638334 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090191 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Andreas Haas authored
R=clemensb@chromium.org Bug: v8:10281 Change-Id: Icf7f8138d0acc172da6ff31935e50de3e4c79e10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096622Reviewed-by:
-
Iain Ireland authored
For a variety of reasons related to OOM handling and custom allocators, SpiderMonkey wants to be able to see all memory allocations. To enforce this, we have a static analysis that verifies that we don't link in malloc/new/etc in unexpected places. One consequence of this is that we can't use STL containers without a custom allocator, because they call operator new internally. This is mostly not an issue in irregexp, which makes heavy use of zone allocation. The main exceptions are a handful of uses of std::vector in regexp-compiler.* and regexp-parser.*. If these vectors are converted to ZoneVectors, then our static analysis is satisfied. R=jgruber@chromium.org Bug: v8:10303 Change-Id: I8b14a2eb54d3b20959e3fbe878f77effae124a2c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091402Reviewed-by:
-
Iain Ireland authored
Unlike the other RegExpTree types, RegExpCapture and RegExpGroup don't cache their min/maxMatch value. Instead, they compute it by recursing on the min/maxMatch of the body node. In pathological cases, with sufficiently small stacks, this can cause stack overflow. (In SpiderMonkey's case, it was a worker on 32-bit x86.) It's easy enough to just precompute the value when the body is set. R=jgruber@chromium.org Bug: v8:10303 Change-Id: I4ba3d301d9a4a3f3c0cb94966148b747a4092d26 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090192 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Iain Ireland authored
TextEmitPass uses a function pointer to determine which pass to call. This function pointer is only assigned inside TextEmitPass, and can easily be eliminated by moving the calls to each possible target inside the switch statement that assigns the function pointer. I made this change because SpiderMonkey uses a static analysis pass to verify that everything is rooted properly across calls that might GC, and that analysis is conservative when calling function pointers. We can white-list function pointers that are known to be safe, but the code being called through this function pointer is complex enough (and the function pointer is unnecessary enough) that it seemed best to just remove the function pointer entirely. R=jgruber@chromium.org Bug: v8:10303 Change-Id: I5fbb0df290a2288c4d3db6d43a563385337162ea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091398 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/3e21004..8a766f0 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a8e510a..786ed18 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/552ddbf..1ee78cd Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/0a95832..ca7cd9b TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I48f6192edf8a261dce59069cdf3aec227fe3875a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2099004Reviewed-by:
-
- 11 Mar, 2020 1 commit
-
-
Andreas Haas authored
The return value of {memory_init_wrapper} was defined as {bool} in the original CL. When compiled with clang, the full return register is written when {true} or {false} is returned. With msvc, however, the return value is written as a single byte, without zero-extension. In generated code, the full return register is used and therefore stale bytes in the return register caused problems. With this CL the return value is changed to {uint32_t}. This enforces zero-extension of the return value and thereby fixes the issue. R=clemensb@chromium.org Bug: v8:10281 Change-Id: I1446e51d88a35def56bd39a8336baa81543497bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096627 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
