- 08 Jan, 2019 40 commits
-
-
Deepti Gandluri authored
Change-Id: I241565dea56db982a46eed8ecdd2fd2692c368ce Reviewed-on: https://chromium-review.googlesource.com/c/1395800Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#58648}
-
Frank Tang authored
Bug: v8:7481 Change-Id: I2587de31faa4dee3ae6f3d5a1872161aae48d1d3 Reviewed-on: https://chromium-review.googlesource.com/c/1395321 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#58647}
-
Frank Tang authored
TC39 accept stable sort in Oct 2018 Bug: v8:7808 Change-Id: I2ad1bca62bda10838dc33acb109a5c937a3b1947 Reviewed-on: https://chromium-review.googlesource.com/c/1400401Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#58646}
-
Frank Tang authored
The spec changed in 7/2018 to treat -0 and 0 differently. https://github.com/tc39/ecma402/pull/232 Bug: v8:7474, v8:8099 Change-Id: I77db4ae716b081b7628dc7ee253a463520c7f6e9 Reviewed-on: https://chromium-review.googlesource.com/c/1400403Reviewed-by:
-
Clemens Hammacher authored
Most parallel moves do not actually require the heavy analysis in the GapResolver since there is no overlap between source and destination registers. Handle some of these cases by a fast-path to avoid the quadratic behaviour in the general case. The fast path is taken for about 2/3 of the non-empty parallel moves on wasm workloads. R=herhut@chromium.org, titzer@chromium.org Bug: v8:8423 Change-Id: I026256fd6cf268f176fccc97f0f427e07629aeb3 Reviewed-on: https://chromium-review.googlesource.com/c/1400410 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Stephan Herhut <herhut@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#58644}
-
Mike Stanton authored
Change-Id: Ifc71ae885b2a08b898ace7f75a8df0ca2b9c3a3d Reviewed-on: https://chromium-review.googlesource.com/c/1275820 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#58643}
-
Maya Lekova authored
TBR=machenbach@chromium.org Bug: v8:8653 NOTRY=true Change-Id: Ifb80024142491649e66114bed2179faa45365b73 Reviewed-on: https://chromium-review.googlesource.com/c/1400843 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#58642}
-
Peter Marshall authored
These flakes can't be reproduced locally so we need more information when they fail. Add some logging so that we can figure out why they are breaking. Bug: v8:8649, v8:8648 Change-Id: I2fb1384bb7592c6fc68c08952505e79329f00bec Reviewed-on: https://chromium-review.googlesource.com/c/1400418 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#58641}
-
Yang Guo authored
R=jgruber@chromium.org Bug: v8:7624 Change-Id: I357e0b9d497ebff03e0e41a3495621c5b4c63464 Reviewed-on: https://chromium-review.googlesource.com/c/1400402 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58640}
-
Peter Marshall authored
Within an inline stack we would have multiple copies of the exact same CodeEntry object to represent an inline frame. We had one copy for every time that the frame appeared in an inline stack. One CodeEntry can have multiple inline stacks and each stack can have multiple inline frames. In the common case, the stacks overlap and repeat frames. This CL creates a single CodeEntry object to represent each inlined function as an inline frame (for a given CodeEntry with inlinings). This removes most of the duplication of inline CodeEntry objects. We still have some duplication, e.g. if we inline bar() into foo() and foo2() but they are not themselves inlined into anything, then we will have two inline CodeEntry objects for bar(). Removing all duplication is harder to achieve because the lifetime of the inlined frame CodeEntry is now no longer tied to the inliner. Get rid of the InlineEntry struct as it is now indentical to CodeEntryAndLineNumber. We store the list of canonical inline CodeEntry objects on the CodeObject of the inlining function so that it can own the lifetimes of inlined frames. Also rename inline_locations_ to inline_stacks_ to be clearer. Bug: v8:7719 Change-Id: Ied765b4cce7fd33f3290798331f1e6767cc42e8c Reviewed-on: https://chromium-review.googlesource.com/c/1396086 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#58639}
-
Toon Verwaest authored
Change-Id: Ie157933d32acf89ff3c1571c843f07ff6fd1c525 Reviewed-on: https://chromium-review.googlesource.com/c/1400782Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58638}
-
Toon Verwaest authored
Bug: chromium:919710 Change-Id: I5a04e76fbc925a89b0ebe1916637f6ae5d109b24 Reviewed-on: https://chromium-review.googlesource.com/c/1400419Reviewed-by:
-
Ross McIlroy authored
Remove the use of a jump table in the prologue of the deopt entries and instead pass the bailout id explicitly in a register when calling the deopt entry routine from optimized code. This unifies the logic with the way the Arm64 code works. It saves the following amount of memory in code stubs: - arm: 384KB - ia32: 480KB - x64: 240KB This could be offset by a slight increase in the size of optimized code for loading the immediate, however this impact should be minimal and will scale with the maximum number of bailout ids (e.g., the size of code will increase by one instruction per bailout id on Arm, therefore ~98,000 bailouts will be needed before the overhead is greater than the current fixed table size). Change-Id: I838604b48fa04cbd45320c7b9dac0de08fd8eb25 Reviewed-on: https://chromium-review.googlesource.com/c/1398224 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#58636}
-
Camillo Bruni authored
Always precheck that the PreparseData has data before serializing it. Drive-by-fix: - rename preparsed_scope_data_builder_ to preparse_data_builder_ Change-Id: I8e709af8f69db44e03caa9132f06a7b8c906bfdb Reviewed-on: https://chromium-review.googlesource.com/c/1387305Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#58635}
-
Michael Achenbach authored
This reverts commit ac2fb66b. Reason for revert: Flakily crashes on several bots: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32/18524 https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20msvc/6824 https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20-%20internal%20snapshot/19766 Original change's description: > [wasm] Remove finisher task > > This removes the finisher task and instead finishes compilation units > from the background. > It also changes ownership of the AsyncCompileJob to be shared among all > tasks that still operate on it. The AsyncCompileJob dies when the last > reference dies. > > R=ahaas@chromium.org > CC=mstarzinger@chromium.org > > Bug: v8:7921, v8:8423 > Change-Id: Id09378327dfc146459ef41bc97176a8716756ae4 > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel > Reviewed-on: https://chromium-review.googlesource.com/c/1335553 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58630} TBR=ahaas@chromium.org,clemensh@chromium.org Change-Id: I6b332b66adaec8f713fb31f4c8517cae7ebb4645 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7921, v8:8423 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Reviewed-on: https://chromium-review.googlesource.com/c/1400420Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#58634}
-
Stephan Herhut authored
Simple experiment that prefers free registers that are not used for arguments to prevent cases where we allocate a free register without hint and thereby block later uses of that register for no good reason. Bug: v8:8311 Change-Id: I95e96b150410e97937cb72d575ae6bece9ee08f9 Reviewed-on: https://chromium-review.googlesource.com/c/1397668Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Stephan Herhut <herhut@chromium.org> Cr-Commit-Position: refs/heads/master@{#58633}
-
Andreas Haas authored
R=titzer@chromium.org Bug: v8:7581 Change-Id: I4725eada889cc8cf6a3ca537f05b1da2f5e83f2b Reviewed-on: https://chromium-review.googlesource.com/c/1400413 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
peterwmwong authored
- Remove macros.py - Inlines macros into d8.js - Remove dead code (macros and message templates) from js2c.py - Remove empty src/js directory Bug: v8:7624 Change-Id: I8dfb69f2f8cb3746b67de816ffc8eb305cbcdee6 Reviewed-on: https://chromium-review.googlesource.com/c/1400150 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by:
-
Clemens Hammacher authored
This removes the finisher task and instead finishes compilation units from the background. It also changes ownership of the AsyncCompileJob to be shared among all tasks that still operate on it. The AsyncCompileJob dies when the last reference dies. R=ahaas@chromium.org CC=mstarzinger@chromium.org Bug: v8:7921, v8:8423 Change-Id: Id09378327dfc146459ef41bc97176a8716756ae4 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Reviewed-on: https://chromium-review.googlesource.com/c/1335553Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58630}
-
Toon Verwaest authored
Previously we'd always push variable proxies into the unresolved list of the current scope, and possibly delete them from the list later in case they end up being declarations. If variables become assigned, there were two ways to mark them as such: The preparser would marked the variables tracked on the PreParserExpression, and the parser would traverse the LHS AST to find and mark all variables. After this CL, if the scope already knows it's tracking declarations, the variables are never added to the unresolved list in the first place. If the scope is ambigous, it tracks the variable proxies on the side and only adds them to the unresolved list if they end up being references rather than declarations. The same list is now used to bulk mark all LHS variables as assigned; uniformely for both the parser and the preparser. In a next step we'll also use the scope to create declarations. That way we can stop tracking variables_ on PreParserExpression altogether. Change-Id: I6ada37006cc2e066731f29cd4ea314550fc7959f Reviewed-on: https://chromium-review.googlesource.com/c/1397669 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Dan Elphick authored
Print all the mismatch failures in the bytecode rather than aborting at the first mismatch. R=rmcilroy Change-Id: Id572ead5fdc4d126ac9a05942f940b0eaef7150f Reviewed-on: https://chromium-review.googlesource.com/c/1400412 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#58628}
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I9214212454034cf1238cab43dc34d8d9f8ed2d37 Reviewed-on: https://chromium-review.googlesource.com/c/1398222Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58627}
-
Clemens Hammacher authored
Backend is split out, so remove backend owners from src/compiler. Also, mention explicitly in src/compiler/backend that also all src/compiler owners are owners there. R=titzer@chromium.org No-Try: true Change-Id: I5409946f65bf27337b715af555083a4804fbb8dd Reviewed-on: https://chromium-review.googlesource.com/c/1400411Reviewed-by:
-
Andreas Haas authored
This CL adds support for anyref in WebAssembly.Global objects. Note that the specification is not complete yet in this area. I did the following changes: - I renamed the `array_buffer` field of WasmGlobalObject to `untagged_buffer` - I added an additional field of type FixedArray, `tagged_buffer`. - In the constructor of WasmGlobalObject I allocate either the former or the latter, but not both. - In the WebAssembly.Global constructor I added special handling for the case where no initial value is provided. In that case I set the inital value to `null` and not to `undefined`. R=titzer@chromium.org Bug: v8:7581 Change-Id: I7e4855d7e6c04a9bcdc7ebd450caca5819d060e2 Reviewed-on: https://chromium-review.googlesource.com/c/1398226 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: -
Dan Elphick authored
Change Object::GetPropertyNames/GetOwnPropertyNames from V8_DEPRECATE_SOON to V8_DEPRECATED. Bug: v8:7286, v8:8562 Change-Id: I2c601e6bf729e8fb68be8bc9a7b1618da61934af Reviewed-on: https://chromium-review.googlesource.com/c/1393285Reviewed-by:
-
Clemens Hammacher authored
If we have both f32 and f64 locals, we use the same register to hold their zero value. On stack transfers, we might thus encounter the same fp register with both the f32 and f64 type. Explicitly allow that case to happen. R=ahaas@chromium.org Bug: chromium:918917, v8:6600 Change-Id: I6937008d38853fe2bdccd9715e1a2499cf6bf7c6 Reviewed-on: https://chromium-review.googlesource.com/c/1398225Reviewed-by:
-
Stephan Herhut authored
On ia32, the instruction selector uses movsx_b to compile the wasm SignExtendWord8ToInt32 instruction. movsx_b requires a byte register as input. However, not all allocatable registers on ia32 are. As we cannot currently express constraints on subsets of registers, this change now forces the input to movsx_b into eax. Bug: chromium:919572 Change-Id: I39bd391974954ec9044940c3164398109eb78908 Reviewed-on: https://chromium-review.googlesource.com/c/1400409Reviewed-by:
-
Dan Elphick authored
Only look 5 frames up the stack when looking for a DCHECK to move the frame to to prevent excessive iteration especially after a stack overflow. Change-Id: I227c46596f09c9af0a47e6673d3165eaccb75163 Reviewed-on: https://chromium-review.googlesource.com/c/1400408Reviewed-by:
-
Jakob Kummerow authored
Two uses in the API needed adaptation; all other uses have already been subsumed by the new implementation (previously known as NeverReadOnlySpaceObjectPtr, here renamed to NeverReadOnlySpaceObject). Bug: v8:3770 Change-Id: Idf0e4a98a407b9afea22e8790da34cf017b892a5 Reviewed-on: https://chromium-review.googlesource.com/c/1397671 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Jakob Kummerow authored
StackHandlers form a chain, where the last element is nullptr, so calling "handler->next()->foo()" is unsafe because "foo" might see "this == nullptr". Bug: v8:3770 Change-Id: Ic989384fa192e29d4d8cb76ff01b32173bf55fd9 Reviewed-on: https://chromium-review.googlesource.com/c/1400406Reviewed-by:
-
Sigurd Schneider authored
Graph width is now managed by the Graph instead of the GraphView, which simplifies some interfaces. Change-Id: If78bc9a469cc8369bc75695a6612627103036bc8 Notry: true Bug: v8:7327 Reviewed-on: https://chromium-review.googlesource.com/c/1398227Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58618}
-
Sigurd Schneider authored
This CL prevents redundancy elimination from widening types, which can cause problems if the input of a DeadValue (which has type None) is replaced by an equivalent node that does not have type None. This can happen because load elimination does not re-type nodes, for example. Bug: chromium:919340 Change-Id: I89e872412edbcdc610e70ae160cde56cd045006c Reviewed-on: https://chromium-review.googlesource.com/c/1397709Reviewed-by:
-
Jakob Gruber authored
Prior to this CL compilation fails with: - 'error: offset of on non-standard-layout type' due to offsetof() - 'Assertion failed: vector subscript out of range' due to the OOB vector subscripts Change-Id: I8751fafd1058ca839de832267811f8f1f47c53fe Reviewed-on: https://chromium-review.googlesource.com/c/1400404Reviewed-by:
-
Jakob Kummerow authored
The two names refer to the same thing by now, so this patch is entirely mechanical. Bug: v8:3770 Change-Id: Ia360c06c89af6b3da27fd21bbcaeb2bdaa28ce22 Reviewed-on: https://chromium-review.googlesource.com/c/1397705Reviewed-by:
-
tzik authored
|argc| parameter of JSEntry is passed as int from C++ code, and loaded into a register on the asm code. As int is 32 bit, and registers are 64 bit on 64 bit platforms, upper 32 bits of the loaded value may be contaminated by a random value if it's passed as a stack parameter. For now, |argc| is passed as a register parameter on all platforms, and the upper 32 bits of |argc| is filled by zero, fortunately. However, if we shuffle the order of parameters, |argc| can be passed as a stack parameter and its value may be broken. Specifically on x64 Windows, the first 4 parameters are passed as register parameters and the rest are stack parameters. As |argc| is the 4th parameter, if we prepend another parameter and shift |argc| to the 5th parameter, |argc| will become a stack parameter and its load to 64 bit register breaks the value. This CL converts the type of the |argc| parameter to intptr_t, so that it's safe to load from stack to full width registers. Bug: v8:8124 Change-Id: Ie7407cf5e6252ed7323a9c42389db387b0064673 Reviewed-on: https://chromium-review.googlesource.com/c/1400326Reviewed-by:
-
Toon Verwaest authored
This is a reland of part of https://chromium-review.googlesource.com/c/v8/v8/+/1397664. It drops the explicit fni_.Infer() call after parsing arrow functions. We'll want to avoid inferring if the arrow function is an argument to a function call. It also avoids adding the single argument of "name => " to the inferred name. Bug: chromium:916975 Change-Id: I96a934408113483d73eba14073fe21e8cfe2ada6 Reviewed-on: https://chromium-review.googlesource.com/c/1397665 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Stephan Herhut authored
The callback to AsyncStreamingProcessor::OnFinishedStream would call into v8 internals without restoring the current context if the processed module had no code. Instead, now always restore the context before doing any finishing work. Bug: chromium:915493 Change-Id: Ib779df81301ad1e3597515a4173c9a57efc593ac Reviewed-on: https://chromium-review.googlesource.com/c/1397672Reviewed-by:
-
Clemens Hammacher authored
We currently hold the register list for {move_src_regs_} in the {StackTransferRecipe} class, and only compute src use counts for executing the moves. Since the use counts and the register list are redundant, just compute the use counts right away, and get rid of the register list. This saves one iteration of the register list in {ExecuteMoves}. R=ahaas@chromium.org Bug: v8:6600, v8:8423 Change-Id: I832fb0d1c1d3afe536289162a81a49b73313e7f4 Reviewed-on: https://chromium-review.googlesource.com/c/1397670 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
Maxim Mazurok authored
- "constuctor" -> "constructor" - "dependendencies" -> "dependencies" - "develpers" -> "developers" - ["nonexistant"][1] -> ["nonexistent"][2] - "reponsible" -> "responsible" [1]: https://en.wiktionary.org/wiki/nonexistant [2]: https://en.wiktionary.org/wiki/nonexistent Change-Id: I8bb482d03c391bd0d37afd5d616229fa50a4ab77 Reviewed-on: https://chromium-review.googlesource.com/c/1390203 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#58610}
-
tzik authored
noexcept keyword needs to be consistent between the declaration and implementation in C++17. Bug: v8:8616, chromium:752720 Change-Id: Iff4022c8c4b861ebdbe8e08995af1bc4da866dae Reviewed-on: https://chromium-review.googlesource.com/c/1396459Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
