- 27 Jan, 2020 16 commits
-
-
Clemens Backes authored
This reverts commit 015f379a. Reason for revert: Msan is unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/30702 Original change's description: > [wasm] Cache streaming compilation result > > Before compiling the code section, check whether the > bytes received so far match a cached module. If they do, delay > compilation until we receive the full bytes, since we are likely to find > a cache entry for them. > > R=clemensb@chromium.org > > Bug: v8:6847 > Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823 > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66000} TBR=clemensb@chromium.org,thibaudm@chromium.org Change-Id: Idfa5b3f354816eb600ae7aab7857063d5d0d27ca No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6847 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022949Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66001}
-
Thibaud Michaud authored
Before compiling the code section, check whether the bytes received so far match a cached module. If they do, delay compilation until we receive the full bytes, since we are likely to find a cache entry for them. R=clemensb@chromium.org Bug: v8:6847 Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Clemens Backes authored
Since the {kFinishedRecompilation} event can happen either before or after the {kFinishedTopTierCompilation} event, we should not check it's order relative to the other events. R=ahaas@chromium.org Bug: v8:10086 Change-Id: I880700b514c7c2238a0eb7791875bf0b81c64e97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020779Reviewed-by:Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65999}
-
Andreas Haas authored
R=clemensb@chromium.org Fix: chromium:1045737 Change-Id: I0e27b8ff6ab09078a2f63f955e6123e1003ed889 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020768Reviewed-by:
-
Steve Blackburn authored
This TODO clarifies intentions of 49f60a3b. Bug: v8:9533 Change-Id: Ide448ae863a8716dafdcdd7fb27801a51655650e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022145Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Steve Blackburn <steveblackburn@google.com> Cr-Commit-Position: refs/heads/master@{#65997}
-
Steve Blackburn authored
Bug: v8:9533 Change-Id: Id51430bb2ad7a782cf30542d0d7117d271079423 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019164Reviewed-by:
-
Ben Noordhuis authored
Utils::ReportApiFailure() contains logic to handle the case where no isolate has been entered but it called Isolate::Current(), which DCHECks when there is no active isolate. Switch to Isolate::TryGetCurrent(). See https://github.com/denoland/rusty_v8/issues/253 for background. Change-Id: I73c28c31102c0c4ab216a925d22ad54174c7911d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020943Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65995}
-
Clemens Backes authored
We often only need to store information about declared (i.e. non-imported) functions in a wasm module. Thus we remove the number of imported function from a function index. We do this in several places, with different amount of checking. This CL extracts this logic to a new {declared_function_index} helper and uses it wherever we do this translation. This more or less establishes the concept of "declared function index" and hopefully prevents errors in the future. R=jkummerow@chromium.org Bug: chromium:1045767 Change-Id: I7e957401495a2a8cb5d2c51031f9c69fe46195d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020763 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Clemens Backes authored
Fix the string representation of functions exported from asm.js modules in the presence of imported functions. R=jkummerow@chromium.org Bug: chromium:1045767, chromium:667678 Change-Id: I55714252036511598eeec7fe7b81985213f7e4f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022142Reviewed-by:
-
Steve Blackburn authored
Deserialization bypasses the heap allocators, bumping pointers into the spaces directly, instead. So the deserializer is tightly coupled to the implementation of the existing collector. Here I've added an interface to heap.h for this purpose. This CL leaves things as-is unless the TPH is enabled, in which case the new interface is used. Future work: use the heap.h interface in all cases. Bug: v8:9533 Change-Id: I3b1cc81870b347fbfb509ddb4031bd3781710240 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019482 Commit-Queue: Steve Blackburn <steveblackburn@google.com> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#65992}
-
Peter Marshall authored
Add a test that does the same thing the devtools-frontend does when evaluating console inputs. 1) Declare a const variable with throwOnSideEffect=true. This should throw. 2) Declare the same const variable with throwOnSideEffect=false. This should successfully declare the variable. Previously it could be the case that even though we threw in 1), the variable would fail to be initialized in 2) with a re-declaration error. Bug: chromium:1043151 Change-Id: I1a6126b518f7bb3788c39b9f8e3adb8850aa962a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016587 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#65991}
-
Liviu Rau authored
Bug: chromium:1033865 Change-Id: I63999575d4962124a4d9a64c4e661900aec5fa6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019167Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Cr-Commit-Position: refs/heads/master@{#65990}
-
Andreas Haas authored
This CL introduces the negb and negw instructions (8-bit and 16-bit versions of neg) in the x64 assembler. These instructions are needed to implement I32AtomicSub8U and similar WebAssembly instructions efficiently. The existing implementation was embedded in a generic macro, and it was difficult to change it without introducing also the 8-bit and 16-bit versions of many other instructions. This would have introduced a lot of dead code. Instead this CL extracted the neg instructions from the macro and implements them directly. This should be fine because the assembler does not change much, and approachability of the code is improved. R=clemensb@chromium.org Bug: v8:10108 Change-Id: I46099bbebd47f864311a67da3ba8ddc4fe4cd35d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019165 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Clemens Backes authored
This extends the API to pass breakpoint information to Liftoff. The Liftoff compiler identifies the places where breakpoints should be set, but does not emit breakpoints yet. This allows us to see the performance overhead of just checking where to emit breakpoints (which should be negligible). R=thibaudm@chromium.org Bug: v8:10147 Change-Id: I3fd40ab9009e9c317a26f70b4f06db512f96a763 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019169Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65988}
-
Justin Ridgewell authored
These both have to do with extremely large numbers, so it's unlikely to cause a problem in practice. Still, correctness. First, encoding `-2147483648` in VLQ returns the value `"B"`. When decoding, we get the value `1` after reading the base64. We then check if the first bit is set (it is) to see if we should negate it, then we shift all bits right once. Now, `value` will be `0` and `negate` will be `true`. So, we'd return `-0`. Which is a bug! `-0` isn't `-2147483648`, and we've broken a round trip. Second, encoding any number with the 31st bit set, we'd return the opposite sign. Let's use `1073741824`. Encoding, we get `"ggggggC"`. When decoding, we get the value `-2147483648` after reading the base64. Notice, it's already negative (the 32nd bit is set, because the 31st was set and we shifted everything left once). We'd then check the first bit (it's not) and shift right. But we used `>>`, which does not shift the sign bit. We actually wanted `>>>`, which will. Because of that bug, we get back `-1073741824` instead of the positive `1073741824`. It's even worse if the 32nd and 31st bits are set, `-1610612736` becomes `536870912` after a round trip. I recently fixed the same two bugs in Closure Compiler: https://github.com/google/closure-compiler/commit/584418eb Change-Id: Ib6592ad50ae3764479c1a766bbb19042ee83b99d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2018882 Auto-Submit: Justin Ridgewell <jridgewell@google.com> Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#65987}
-
Jakob Gruber authored
When printing the source string, a backslash-newline sequence ('\\\n', '\\\r', '\\\u2028', '\\\u2029') should be formatted as '\n', '\r', '\u2028', '\u2029', respectively. Prior to this CL it was formatted as a backslash followed by the literal newline character. Bug: v8:8615 Change-Id: Iac90195c56ea1707ea8469066b0cc967ea87fc73 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016583 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:Georg Neis <neis@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#65986}
-
- 24 Jan, 2020 23 commits
-
-
Johannes Henkel authored
Fixes edge cases for parsing / serializing codepoint 0xffff in JSON with UTF16. New Rev: 0213a8545f6362cd1cd5091cedf29747736552e8 Change-Id: I48b174cf1bd9263ace002996094f7143a1248766 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020502 Auto-Submit: Johannes Henkel <johannes@chromium.org> Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#65985}
-
Dominik Inführ authored
When ArrayBufferExtensions are enabled, sweep the extensions outside of the GC pause concurrently to the application. The following GC will make sure that the previous concurrent sweep operation is finished. This CL introduces Heap::array_buffer_sweeper() that is both responsible for tracking all extensions but also for sweeping. Bug: v8:10064 Change-Id: I113cd625445a7d59ffb7a9de8b25a15a72b02b99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010107Reviewed-by:
-
Ng Zhi An authored
Remove the execution tier check for simd tests. On archs without Liftoff, those tests that are configured to run on Liftoff will fail with this check, since they bail out to TF. We remove this check for now, but will think of a way to enforce this in a more platform specific way. Bug: v8:9909 Change-Id: Id56f841fe6e342434af3dbcdaef0a8a284614994 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019924Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
-
Toon Verwaest authored
Otherwise the side effect is already applied before we throw the exception, already breaking the environment. Bug: chromium:1043151 Change-Id: I6d6b4706481bd8eaead6de3503aabc4bad9fb6de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016597 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Andreas Haas authored
R=thibaudm@chromium.org CC=ecmziegler@chromium.org Change-Id: I3f34dc69e5ec7e4a5872c740788812367ae56a5f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019166Reviewed-by:
-
Peter Marshall authored
SafeStackFrameIterator::Advance() will stop at wasm_to_js frames, so we should fully expect that they show up when calling frame() after Advance(). This fixes some breakages for profiling wasm and asm.js. Bug: chromium:1010534, v8:10150 Change-Id: Ifc78cd9eba33e777b33fc1cbea19ee376b25299c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019485Reviewed-by:
-
Milad Farazmand authored
Change-Id: Ic97cf0488c601e524f4965ee84147f9a70857512 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019583Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#65979}
-
Al Muthanna Athamina authored
This CL attempts to remove the #undef check from the Presubmit for .cc files because we are removing Jumbo support. Bug: chromium:994387 Change-Id: I1bb6d22393c1b533f23dd586e5028ecc6d254c99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013119Reviewed-by:
Wez <wez@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port b110d480 Original Commit Message: This relands commit 009993ad. The fix is in liftoff-assembler-ia32.h, the codegen was incorrect. Original change's description: > Implement f32x4.splat and enable handling this in Liftoff. > > We add a new macro for defining test cases to run on TurboFan, Liftoff, > interpreter, and scalar lowering. > > Also add an assertion that the execution tier used is what we expected > it to be. This is useful for Liftoff, because by default it falls back > to TurboFan when it encounters an unimplemented opcode. > > Bug: v8:9909 R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I0fc54cd04379a6c65aa2bee64bf4cf9dad5b9636 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019582Reviewed-by:
-
Clemens Backes authored
As these are simple methods, and for consistency with the GraphAssembler interface, the getters should not be capitalized. R=ecmziegler@chromium.org Bug: v8:10123 Change-Id: I51871115b061bca4483dc23e982303508d9d8f55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017471 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Clemens Backes authored
This changes the WasmGraphBuilder to use the GraphAssembler for storing the current effect and control, instead of having separate fields. This will allow us to use GraphAssembler methods anywhere in the WasmGraphBuilder without first transferring the WasmGraphBuilder's effect and control to the GraphAssembler and storing it back afterwards. Some methods (StackCheck, BuildCallToRuntimeWithContext) have been changed to work on the current effect and control instead of receiving them as parameters. This is necessary to also use the GraphAssembler there, and it makes the code a bit easier. R=ecmziegler@chromium.org Bug: v8:10123 Change-Id: Ia9f6359cfe44a67a875c3eb0fe51f87db8bd17db Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017470 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Michael Achenbach authored
Bug: v8:8292 Change-Id: Icbfb8cb0c4ba9cdb5a6c1cbec5e4c6e61c9d0d4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019163Reviewed-by:
Liviu Rau <liviurau@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65974}
-
Clemens Backes authored
TailCalls have no output effect, similarly to e.g. return nodes. Thus, don't put them in the effect chain. The current graph verifier does not complain about this, but once we switch to the GraphAssembler, we will hit a SLOW_DCHECK there because we are trying to use a node as effect which has no effect output. R=jkummerow@chromium.org Bug: v8:10070 Change-Id: I23d9516eb9bd42a5aca46b09ca74830eafce635c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017474 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Clemens Backes authored
We currently print asm.js functions converted to wasm as "function foo() { [native code] }", even though without asm to wasm translation we get the proper source code. This is an observable difference that should not be, and also foozzie finds this frequently in different variations. This CL makes us remember the start position (position of the "function" token) and end position (right behind the closing "}") of each function we transform to wasm. These offsets, together with the Script that contained the function, allows us to reconstruct the source code of the function for the {toString()} method. R=jkummerow@chromium.org Bug: chromium:667678 Change-Id: If22471cad4cefdfc67f6d1b8fda85aa0eeb411bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016582 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Liviu Rau authored
Bug: chromium:1033865 Change-Id: Id20517aa4a8a0bbc6e9cf593ce29504f16297e5d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017473Reviewed-by:
-
Clemens Backes authored
The code did originally only handle the int32 case, but was then extended to all wasm types in https://crrev.com/c/1965577. The comments and variable names still mention the int32 type only though. This CL fixes that. R=ecmziegler@chromium.org Bug: v8:10070 Change-Id: I3b1fa4047ee7ee9f283dce3758f6b8a39c964b22 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017723 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Clemens Backes authored
This code is commented out since a long time (at least since 2008), but I found it to be useful information. Instead of printing the full script information, just print the {Brief} version. In a debugger, users can still print the full information based on the printed pointer value if needed. R=jkummerow@chromium.org Change-Id: I79b19f0bbc8797746b916c1f5860f727c0f0ac39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2015240Reviewed-by: -
Clemens Backes authored
... and fix comments which I accidentally changed back to an old version in https://crrev.com/c/2011086/. R=jkummerow@chromium.org Bug: chromium:667678 Change-Id: I2a801d9775bd2362290c5d1caaf5b9e24a9bd54d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2015241 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Emanuel Ziegler authored
R=jkummerow@chromium.org Bug: chromium:1043036 Change-Id: Idf44e21254a5d7131c4ec6e4c22fa4d4b25f617b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016590Reviewed-by:
-
Shu-yu Guo authored
Bug: v8:8179 Change-Id: I2e7024412216decc06e814e88eecd5b4eb5ae8cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013696Reviewed-by:
Ben Smith <binji@chromium.org> Reviewed-by:
-
Shu-yu Guo authored
Bug: v8:8179 Change-Id: I3a41243b971d499d50e35c4782bff5b8b012f434 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013695 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#65965}
-
Johannes Henkel authored
This cleans up string-util.h a little. Instead of distinguishing BinaryStringBuffer from StringBufferImpl (which has a legacy ::adopt() interface), provide two functions for making StringBuffer from either an 8 bit (std::vector<uint8_t>) or a 16 bit (String16) source, and keep the classes in the .cc file only. Since it's easy enough, this adds a class also for the empty string buffer as there's no need to keep an empty vector / String16 this way. No public API changes here. Change-Id: Idb25fe24ea94f27f8001d552cede089e04eacd32 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016015Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Ng Zhi An authored
This relands commit 009993ad. The fix is in liftoff-assembler-ia32.h, the codegen was incorrect. Original change's description: > Implement f32x4.splat and enable handling this in Liftoff. > > We add a new macro for defining test cases to run on TurboFan, Liftoff, > interpreter, and scalar lowering. > > Also add an assertion that the execution tier used is what we expected > it to be. This is useful for Liftoff, because by default it falls back > to TurboFan when it encounters an unimplemented opcode. > > Bug: v8:9909 Bug: v8:9909 Change-Id: I7daacbe8b195d9212367190c515b0babbc457a88 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2018043Reviewed-by:
-
- 23 Jan, 2020 1 commit
-
-
Seth Brenith authored
This fixes an issue found by the upcoming change that verifies a match between 32-bit Torque output from a 32-bit build and 32-bit output from a 64-bit build: https://crrev.com/c/v8/v8/+/1998078 . 32-bit output never needs to deal with pointer compression. Bug: v8:10124 Change-Id: I0e04728dafc4118a8816a3afa98651dddea7a574 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2001460Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65962}
-
