- 17 Mar, 2017 36 commits
-
-
dusan.simicic authored
BUG= Review-Url: https://codereview.chromium.org/2759673002 Cr-Commit-Position: refs/heads/master@{#43915}
-
neis authored
Typer::Visitor::ToLength was unsound (and non-monotonic). For instance, if the input type was Range(2^53, 2^53+1), the result type was Constant(2^53). Now the result is type Constant(2^53-1). (The result of ToLength is guaranteed to be between 0 and 2^53-1.) BUG= Review-Url: https://codereview.chromium.org/2753773010 Cr-Commit-Position: refs/heads/master@{#43914}
-
bbudge authored
BUG=none Review-Url: https://codereview.chromium.org/2759513002 Cr-Commit-Position: refs/heads/master@{#43913}
-
jbroman authored
This makes it more similar to other handle types (like PersistentBase), by simply storing an i::Object** cast to T*. This means that it is not necessary to look up the handle in the eternal handles table to access the underlying value. Like the built-in roots (null, etc.), an eternal handle can never be destroyed, so we don't even need to allocate a separate local handle. Instead, the Local<T> can point directly at the eternal reference. This makes Eternal<T>::Get trivial. Review-Url: https://codereview.chromium.org/2751263003 Cr-Commit-Position: refs/heads/master@{#43912}
-
Jochen Eisinger authored
BUG=v8:6069 R=rmcilroy@chromium.org Change-Id: I0e1096e20fa96af0a4875704f3f90e8458750356 Reviewed-on: https://chromium-review.googlesource.com/456557Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#43911}
-
jgruber authored
NOTREECHECKS=true TBR=machenbach@chromium.org Review-Url: https://codereview.chromium.org/2754283002 Cr-Commit-Position: refs/heads/master@{#43910}
-
jgruber authored
Default to the chromium-internal build config (instead of the more permissive no_chromium_code config). BUG=v8:5878 Review-Url: https://codereview.chromium.org/2758563002 Cr-Commit-Position: refs/heads/master@{#43909}
-
Marja Hölttä authored
The data needed to be modified a bit to actually allow skipping over functions based on it. In particular, we need to allow skipping over an unknown inner scope structure (in the previous stage, we just had tests comparing the data against some baseline truth, so it wasn't needed). also removing the current "skip functions based on preparse data" logic, since preparser data is not used any more. At a later stage, I'll consider plugging the preparser-scope-analysis-data into that pipeline (so I don't want to remove the full code yet). Integration to the various forms of compilation is still incomplete; this CL integrates just enough to get the minimal example to pass: (function foo() { function preparsed() { var var1 = 10; function skip_me() { print(var1); } return skip_me; } return preparsed; })()()(); BUG=v8:5516 Change-Id: I0d24b4c3b338f7e6b6c3bf7cf2c1ceb29608e2f2 Reviewed-on: https://chromium-review.googlesource.com/446336 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#43908}
-
jbroman authored
They do not modify the state of the handle. Review-Url: https://codereview.chromium.org/2753973002 Cr-Commit-Position: refs/heads/master@{#43907}
-
Toon Verwaest authored
We don't invalidate the map of the global object anymore. BUG=v8:5561 Change-Id: I006066e9b675dd3d118efc8d00687b97419c427b Reviewed-on: https://chromium-review.googlesource.com/456417Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#43906}
-
georgia.kouveli authored
This shows an improvement in the code size of the bytecode handlers. When a range is split (because for example the preferred register gets clobbered by a call and is not available for the whole range), trying to allocate the preferred register for the first range that results from the split avoids some extra register moves. BUG= Review-Url: https://codereview.chromium.org/2749023005 Cr-Commit-Position: refs/heads/master@{#43905}
-
jkummerow authored
NOTRY=true Review-Url: https://codereview.chromium.org/2754253002 Cr-Commit-Position: refs/heads/master@{#43904}
-
Wiktor Garbacz authored
Parse tasks are still WIP so there is really no benefit turning them on. Turn off irrelevant tests. Fix duplicate parameters inverted logic. Fix use_counts tracking. Fix language mode, super_property, evals. Fix modules and stack overflow. BUG=v8:6093 Change-Id: I8567b36eef7b9de6799789e7520810bde9c86e5b Reviewed-on: https://chromium-review.googlesource.com/455916 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43903}
-
Michael Starzinger authored
R=jarin@chromium.org Change-Id: Ib8f657957895f703189f2347f5d8017e16de05ae Reviewed-on: https://chromium-review.googlesource.com/455798Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43902}
-
Leszek Swirski authored
Don't trash stdout with "dropped: overflow" messages (or other errors) in the log reader, which then cause generated json files to fail to be read by other tools. Change-Id: Ie27639dbbee6fc9e8da0bc6901667c3a2835fbef Reviewed-on: https://chromium-review.googlesource.com/456499Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#43901}
-
titzer authored
This CL renames all occurrences of "internal field" to "embedder field" to prevent confusion. As it turns out, these fields are not internal to V8, but are actually embedder provided fields that should not be mucked with by the internal implementation of V8. Note that WASM does use these fields, and it should not. BUG=v8:6058 Review-Url: https://codereview.chromium.org/2741683004 Cr-Commit-Position: refs/heads/master@{#43900}
-
Michael Starzinger authored
This is a first stab at extending the existing early lowering approach to property access operations. Currently we only handle the case where named property loads are lowered to a soft deoptimize operation, due to insufficient type feedback. R=jarin@chromium.org Change-Id: I779ffb99978023237da5ad9eaf0241fe74243882 Reviewed-on: https://chromium-review.googlesource.com/456316 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#43899}
-
Yang Guo authored
During bootstapping installing native functions may cause map transitions. There are no dependent code groups, but the assertion still triggers. BUG=chromium:617892 Change-Id: Id7cb87575a0fe176e7aff785d4dd249db44deec8 Reviewed-on: https://chromium-review.googlesource.com/457036Reviewed-by: Jochen Eisinger <jochen@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#43898}
-
jgruber authored
ToDirectStringAssembler is used in StringCharCodeAt and SubString (which uses StringCharCodeAt internally). SubString is used all over the place (e.g. RegExp result construction), and is critical for benchmark performance. The CL introducing ToDirectStringAssembler caused a couple of regressions which this is intended to fix by adding a fast path for sequential strings. BUG=chromium:702246 Review-Url: https://codereview.chromium.org/2754933003 Cr-Commit-Position: refs/heads/master@{#43897}
-
Toon Verwaest authored
The ForDeopt stub isn't actually necessary anymore; but I don't want to fix the deoptimizer in the same CL. BUG=v8:5561 Change-Id: I7101cec4b783949bcfbf1ebdb80541d1b558e2e2 Reviewed-on: https://chromium-review.googlesource.com/455858 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#43896}
-
Marja Hölttä authored
There are at least 3 mechanisms for detecting duplicate parameters. - ExpressionClassifier - Scope::DeclareParameter checking IsDeclaredParameter - PatternRewriter::VisitVariableProxy failing to declare a duplicate parameter The conditions for when duplicate parameters are allowed and when not are pretty involved too. They are allowed when - the function is not an arrow function and not a concise method *and* - when the parameter list is simple *and* - we're in sloppy mode (incl. the function doesn't declare itself strict). In addition, we don't recognize some of the early errors, and it's non-trivial to see which ones are recognized and which not (see bug v8:6108). E.g., (dup, dup) => {}; is recognized but (dup, [dup]) => {} is not. And (dup, [dup]) => 1; is. We do have tests for some aspects of duplicate parameters (e.g., arrow function duplicate parameters are included in arrow function tests), but it's hard to see whether all combinations of the relevant conditions are tested. This CL adds more structured tests which hopefully enables reducing the duplicate parameter detection mechanisms to 2 or maybe even to 1. BUG=v8:6092 Change-Id: Idd3db43b380aae4b9a89be5f1ed0755d39bfb36d Reviewed-on: https://chromium-review.googlesource.com/456336 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#43895}
-
Leszek Swirski authored
When displaying a single function's timeline, display all its variants (colour-coded by kind) instead of just the ones with the same code-id. This allows us to see all optimised versions of a function, as well as changes between optimised and unoptimised. Drive-by -- Do some rounding to get rendering pixel-perfect. Change-Id: I385c83b39414ac5e59208b7a25b488d6a283e2b0 NOTRY=true Change-Id: I385c83b39414ac5e59208b7a25b488d6a283e2b0 Reviewed-on: https://chromium-review.googlesource.com/455833 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#43894}
-
clemensh authored
Revert of MIPS[64]: Fix unaligned arguments storage in Wasm-to-interpreter entry (patchset #3 id:40001 of https://codereview.chromium.org/2705293011/ ) Reason for revert: Did not fix the issue. Original issue's description: > MIPS[64]: Fix unaligned arguments storage in Wasm-to-interpreter entry > > In Wasm-to-interpeter entry creation, arguments for the interpreter > are stored in an argument buffer. Depending on the order of the > arguments some arguments may be misaligned and this causes crashes > on those architectures that do not support unaligned memory access. > > TEST=cctest/test-wasm-interpreter-entry/TestArgumentPassing_AllTypes > BUG= > > Review-Url: https://codereview.chromium.org/2705293011 > Cr-Commit-Position: refs/heads/master@{#43476} > Committed: https://chromium.googlesource.com/v8/v8/+/84ff6e4c1997b63c01e95504c31ee6c5504430d5 TBR=titzer@chromium.org,ivica.bogosavljevic@imgtec.com # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= Review-Url: https://codereview.chromium.org/2760603002 Cr-Commit-Position: refs/heads/master@{#43893}
-
Jochen Eisinger authored
BUG=none R=yangguo@chromium.org Change-Id: I53811859efacee9126ba1bdbe5690793833c96e1 Reviewed-on: https://chromium-review.googlesource.com/456338 Commit-Queue: Jochen Eisinger <jochen@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#43892}
-
bmeurer authored
Revert of [ignition] Decrease code size multiiplier to 24. (patchset #1 id:1 of https://codereview.chromium.org/2758503002/ ) Reason for revert: Doesn't seem to help with peak performance, and seems to hurt startup performance a bit, so reverting for now Original issue's description: > [ignition] Decrease code size multiplier to 24. > > BUG= > > Review-Url: https://codereview.chromium.org/2758503002 > Cr-Commit-Position: refs/heads/master@{#43861} > Committed: https://chromium.googlesource.com/v8/v8/+/b880309bc7f2c4be67f12bac04249f09b0fdd66d TBR=rmcilroy@chromium.org,jarin@chromium.org,danno@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2751913007 Cr-Commit-Position: refs/heads/master@{#43891}
-
neis authored
This is a first step towards moving Turbofan code generation off the main thread. Summary of the changes: - AssemblerBase no longer has a pointer to the isolate. Instead, its constructor receives the few things that it needs from the isolate (on most architectures this is just the serializer_enabled flag). - RelocInfo no longer has a pointer to the isolate. Instead, the functions that need it take it as an argument. (There are currently still a few that implicitly access the isolate through a HeapObject.) - The MacroAssembler now explicitly holds a pointer to the isolate (before, it used to get it from the Assembler). - The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since it's not used at all in the Assemblers. - A few architectures implemented parts of the Assembler with the help of a Codepatcher that is based on MacroAssembler. Since the Assembler no longer has the isolate, but the MacroAssembler still needs it, this doesn't work anymore. Instead, these Assemblers now use a new PatchingAssembler. BUG=v8:6048 Review-Url: https://codereview.chromium.org/2732273003 Cr-Commit-Position: refs/heads/master@{#43890}
-
jgruber authored
CSA builtins can become very large, and the RegExp builtins are currently the main offender (e.g. @@match's code size is over 50k). This is due to the fact that most RegExp builtins rely on RegExpBuiltinExec (fairly large itself), which is then inlined multiple times in many builtins. This CL reduces the snapshot size for an x64 release build by 80k by turning slow-path RegExpBuiltinExec calls into stub calls (i.e. removing code duplication through inlining) and completely removing the code path for fast RegExp instances in RegExpExec (it is never taken). BUG=v8:5339,v8:5737 Review-Url: https://codereview.chromium.org/2745053003 Cr-Commit-Position: refs/heads/master@{#43889}
-
Toon Verwaest authored
BUG=v8:5561 Change-Id: Ib344479dac691bc418fbedffffbfbc1380ddd369 Reviewed-on: https://chromium-review.googlesource.com/455937 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#43888}
-
Andreas Haas authored
Since TrapIf has been implemented on all platforms, there is no need anymore for the old WasmTrapHelper code. This CL also removes TrapIf-specific tests. R=titzer@chromium.org, clemensh@chromium.org Change-Id: Ic069598441b7bd63bde2e66f4e536abea5ecebe6 Reviewed-on: https://chromium-review.googlesource.com/452380 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#43887}
-
jgruber authored
test-unboxed-doubles/WriteBarrierObjectShiftFieldsRight recently started failing on arm64-nosnapshot builds due to a broken CHECK. # Fatal error in ../../test/cctest/test-unboxed-doubles.cc, line 1417 # Check failed: heap->InNewSpace(*obj_value). It expects the result of Factory::NewJSArray() to be in new space; but NewJSArray encapsulates two allocations so the return value can actually be in old space. Fix it by ensuring only one allocation occurs. BUG=v8:5339 Review-Url: https://codereview.chromium.org/2759433002 Cr-Commit-Position: refs/heads/master@{#43886}
-
neis authored
R=jarin@chromium.org BUG= Review-Url: https://codereview.chromium.org/2753543009 Cr-Commit-Position: refs/heads/master@{#43885}
-
Clemens Hammacher authored
The WasmCompileLazy builtin creates an internal frame, thus the garbage collector will visit all pointers in the stack frame. However, we will call this builtin from compiled wasm code, and it receives raw (untagged) arguments. This is because this builtin is later exchanged by compiled wasm code, so the ABI needs to be compatible. This CL introduces the has_tagged_params code flag, which is true by default and false for each WASM_FUNCTION, JS_TO_WASM_FUNCTION and the WasmCompileLazy builtin. The gargabe collector just ignores the parameters for each frame whose code object has this flag set to false. For internal frames, all pointers in the whole stack frame are ignored if the flag is set. R=titzer@chromium.org, mstarzinger@chromium.org BUG=v8:5991 Change-Id: I12a15157db344725bcc280e2041fd5bcad2ba700 Reviewed-on: https://chromium-review.googlesource.com/451400 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43884}
-
Jochen Eisinger authored
Retrieving information from a message should never execute script or throw exceptions. BUG=v8:5830 R=mmoroz@chromium.org,yangguo@chromium.org Change-Id: Ie8a84ca2cc14eb41ceaf4162d8a5381a20d559bc Reviewed-on: https://chromium-review.googlesource.com/455740 Commit-Queue: Jochen Eisinger <jochen@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#43883}
-
littledan authored
String case conversion is known to debug-evaluate to not have a side effect in noi18n mode, but debug-evaluate thinks it has a side effect in i18n mode. Update the tests accordingly. Verified locally that the test passes in i18n and noi18n mode (not sure whether the noi18n trybot executes this test). CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng Review-Url: https://codereview.chromium.org/2750403004 Cr-Commit-Position: refs/heads/master@{#43882}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/81c2772..72004d5 Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/d49bf81..7b2dc0f TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Change-Id: I4a4903fd29b31585e184d9a5ccb5a4a941e7756c Reviewed-on: https://chromium-review.googlesource.com/456461Reviewed-by: v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#43881}
-
gdeepti authored
DetachArrayBuffer makes incorrect assumptions about the state of the ArrayBuffer. It assumes that that the ArrayBuffer is internal to wasm unless guard pages are enabled, this is not the case as the ArrayBuffer can be externalized outside of wasm, in this case through gin. BUG=chromium:700384 Review-Url: https://codereview.chromium.org/2754153002 Cr-Commit-Position: refs/heads/master@{#43880}
-
- 16 Mar, 2017 4 commits
-
-
allada authored
Stacktrace data is now passed when scriptParsed event is triggered. R=kozyatinskiy@chromium.org,dgozman BUG=chromium:646849 Review-Url: https://codereview.chromium.org/2755863002 Cr-Commit-Position: refs/heads/master@{#43879}
-
aseemgarg authored
BUG=v8:4614 R=binji@chromium.org Review-Url: https://codereview.chromium.org/2649703002 Cr-Commit-Position: refs/heads/master@{#43878}
-
bjaideep authored
Port 5cc61896 Minor fix to the original CL's port of ppc/s390 Original Commit Message: This moves most of the logic contained in RegExpExecStub to CSA. Benefits are mostly easier readability and hackability, and removal of a large chunk of platform-specific assembly. Exit frame construction and the final call remain in RegExpExecStub. R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5339,v8:592 LOG=N Review-Url: https://codereview.chromium.org/2757673004 Cr-Commit-Position: refs/heads/master@{#43877}
-
jyan authored
R=joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com Review-Url: https://codereview.chromium.org/2756733002 Cr-Commit-Position: refs/heads/master@{#43876}
-