- 09 Jun, 2017 22 commits
-
-
Clemens Hammacher authored
This CL changes the printed wasm locations to use the spec'ed format (see https://github.com/WebAssembly/design/blob/master/Web.md#developer-facing-display-conventions). Before: <WASM[<id>]+<offset> After: wasm-function[<id>]:<offset> R=ahaas@chromium.org Change-Id: If8018012b518143d6353f5a1f5319764ee46f148 Reviewed-on: https://chromium-review.googlesource.com/529104Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45820}
-
Michael Starzinger authored
R=cbruni@chromium.org BUG=v8:6474 Change-Id: I84be45bab041082cc66b5fdd70a9e799a44facee Reviewed-on: https://chromium-review.googlesource.com/529207Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45819}
-
Toon Verwaest authored
Shape also contains the Key type. Read it through there instead. Bug: v8:6474 Also-By: cbruni@chromium.org Change-Id: Ia47f6143c671c104901a714d4151c9fe9f525b5f Reviewed-on: https://chromium-review.googlesource.com/529305Reviewed-by:
-
Daniel Ehrenberg authored
In some [1] cases where a lexical declaration is not allowed, ASI will cause a `let` at the end of a line to be interpreted as an identifier. A recent patch [2] to fix up the error messages from misplaced `let` usage was a little overzealous in triggering the error, throwing a SyntaxError in this edge case. This patch restores the ASI behavior, which is permitted in JSC and SpiderMonkey as well. Thanks to a test262 test from Andre Bargull for raising this issue. [1] https://tc39.github.io/ecma262/#sec-expression-statement [2] https://codereview.chromium.org/2697193007 Bug: v8:3305 Change-Id: I80ae8ad9a8a93389ff1003323f0d3f003e7a8c8e Reviewed-on: https://chromium-review.googlesource.com/529225Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45817}
-
Clemens Hammacher authored
And in one case just remove it since it is superflous. R=mstarzinger@chromium.org BUG=v8:6474 Change-Id: I60bfac75f5d65a56c7ca8d67923e9314ec703eac Reviewed-on: https://chromium-review.googlesource.com/529244Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45816}
-
Wiktor Garbacz authored
Change-Id: I2d8f4defd465b2f9838ed002add088da5b6739ef Reviewed-on: https://chromium-review.googlesource.com/528197Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#45815}
-
Toon Verwaest authored
Bug: v8:6474 Also-By: cbruni@chromium.org Change-Id: I1aefa1156b89a7f8ffafe27e58cacbfecc9a1d02 Reviewed-on: https://chromium-review.googlesource.com/528885Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#45814}
-
Ulan Degenbaev authored
This reduces confusion with GC write barrier. The word "barrier" is reserved for GC write barrier and "fence" for memory ordering fence. BUG=v8:6474 Change-Id: Ic4352f04430eaca742b72db1580ee0a42a1ffefb Reviewed-on: https://chromium-review.googlesource.com/528103Reviewed-by:
-
Andreas Haas authored
The wasm-code fuzzer used different parameters for the interpreter and the generated code due to a typo. This typo is fixed by this CL. R=clemensh@chromium.org Change-Id: Ia9c72b83e7722e0a8b3fe6efb3f4b32ca5c937ab Reviewed-on: https://chromium-review.googlesource.com/527447Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#45812}
-
Wiktor Garbacz authored
Also, as this is hard to track down, always DCHECK position after ReadBlock(). Change-Id: Ie32c3a311dd8df91f651b6d82ccacc7c95e6fde0 Reviewed-on: https://chromium-review.googlesource.com/528196 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#45811}
-
Clemens Hammacher authored
base::Optional is a replacement for std::optional, until we switch to C++17 and can use std::optional directly. The implementation is copied from chromium's base::Optional, but put in the {v8::base} namespace instead of just {base}. Also, the specialization of std::hash for base::Optional is omitted, since it's disallowed in the style guide. A first use in the AsmJsParser is introduced, if that one sticks, I will refactor more uses of std::unique_ptr to use base::Optional instead, avoiding the heap allocation. R=mstarzinger@chromium.org BUG=v8:6474 Change-Id: I019599d4bf9ff0105bf592dfb96d6050feba18ae Reviewed-on: https://chromium-review.googlesource.com/528884 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
Marja Hölttä authored
ExpressionClassifier was used just for transmitting information back and forth to DeclareFormalParameters. As a bonus, we now do the Scope::IsDeclaredParameter check only when we're going to use the information it produces. BUG=v8:6092,v8:6474 Change-Id: Ib5ac6a779705caa74e933e1c6f03eaaf0f49bf05 Reviewed-on: https://chromium-review.googlesource.com/455836 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#45809}
-
Mythri authored
All the bytecode handlers were added a one test, so we would get a total on all of the bytecode handler benchmarks. It is not a good indicator when we total unrelated benchmarks. So added more categories to group only related benchmarks together. This also makes it easier to look at the results. Bug: chromium:730628 Change-Id: I1c5858f40c1ce584c4b7bd833a7f3c52a43d07c6 Reviewed-on: https://chromium-review.googlesource.com/527436 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45808}
-
jgruber authored
The mips/mips64 port of http://crrev.com/2909893002. Original commit message: DebugInfo was very closely tied to break point support: * It contained only information relevant to break points. * It was created and freed by break point implementation. * Existence of a DebugInfo on the shared function info implied existence of break points. This CL is a step towards making DebugInfo usable by other debugging functionality such as block coverage by decoupling it from break point support, which is now only one kind of information stored on the DebugInfo object. BUG=v8:6000 Change-Id: Ia770ff3c048022652d8abbe30d372fde5cb452a4 Reviewed-on: https://chromium-review.googlesource.com/528112Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45807}
-
Ulan Degenbaev authored
This makes popping from the marking deque safe for concurrent marking. BUG=chromium:694255 Change-Id: I3edf8ece3d3c3dd8f045b3ea2f8196b322a56a54 Reviewed-on: https://chromium-review.googlesource.com/527154 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Alexandre Talon authored
In some codes flushing the registers was costly: we processed each register whereas all the registers alone in their equivalence class need not to be processed. We now overapproximate easily which classes are of size 2 so as to save many iterations in the Flush() loop in some cases. Bug: v8:6432 Change-Id: I945e151736e8a515263ac76312127d930fd20d74 Reviewed-on: https://chromium-review.googlesource.com/525795 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45805}
-
Igor Sheludko authored
Use convenient macros for accessing bit fields. Bug: v8:6470 Change-Id: Iada9779ce56c7ca2e8b6a9617c236e294db7325e Reviewed-on: https://chromium-review.googlesource.com/527432 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Michael Starzinger authored
This removes the ability of the compilation pipeline to invoke the Crankshaft optimizing compiler for JavaScript functions. Note that in this state Crankshaft can still be used to compile code stubs. R=rmcilroy@chromium.org BUG=v8:6408 Change-Id: I0bec7c8ec7c705c13257df43796403a228ea631c Reviewed-on: https://chromium-review.googlesource.com/527443Reviewed-by:
-
Daniel Ehrenberg authored
In sloppy mode, allow multiply labelled function declarations, such as a: b: function c() {} Such a form is allowed by the specification, as well as ChakraCore, SpiderMonkey and JSC (though ChakraCore because it doesn't enforce any lexical label restrictions.) Thanks to Andre Bargull for adding the test262 test which caught the bug. Change-Id: I2d3f172830c2e63252f00afa03177a7d17d79a27 Reviewed-on: https://chromium-review.googlesource.com/527639Reviewed-by: -
bmeurer authored
The JSCreateClosure operator was not marked as Eliminatable, esp. it wasn't marked as NoWrite (read: no JavaScript observable side-effect), which lead to a weird performance cliff with the new Array builtin inlining. For example a.forEach(c => c); was not inlined, whereas const f = c => c; a.forEach(f); was properly inlined, despite not causing any trouble for TurboFan in general. The reason was that the JSCreateClosure for the arrow function was marked as "can cause potential side effect", which it cannot. This fixes the operator to be properly marked as Eliminatable, thus removing this performance cliff. BUG=v8:1956,v8:6475 R=danno@chromium.org Review-Url: https://codereview.chromium.org/2930933002 Cr-Commit-Position: refs/heads/master@{#45801}
-
Michael Starzinger authored
Both Ignition and TurboFan have been enabled by default for a while. This just disentangles the implication between those two flags and sets the --ignition individually. They can now be controlled individually. R=rmcilroy@chromium.org BUG=v8:6408 Change-Id: I08eca85120160efa5868b5ca36d1613964ed82eb Reviewed-on: https://chromium-review.googlesource.com/527637Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45800}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9d6666d..41581bc Rolling v8/tools/swarming_client: https://chromium.googlesource.com/external/swarming.client/+log/5c4eed8..af6b06c TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Change-Id: If888be1ca55a3eda40e6e6dd7e38f351d3b3ab6d Reviewed-on: https://chromium-review.googlesource.com/527359Reviewed-by:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#45799}
-
- 08 Jun, 2017 18 commits
-
-
bjaideep authored
Port 90c3a2d5 Original Commit Message: This CL contains a few pieces: - A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan graphs, which--when triggered--swizzle the values in the the FrameState to be parameters to a typically TF-generated builtin that resumes execution to finish the slow-case functionality. - Continuation builtins that have special handling in the deoptimizer and their own new frame type to ensure that the values they need to begin executing can be stashed away and restored immediately before the builtin is called via a trampoline that runs when the continuation builtin's frame execution resumes. - An implementation of Array.prototype.forEach in TurboFan that can be used to inline it. The inlined forEach implementation uses the checkpoints mechanism described above to deopt in the middle of the forEach in the cases that optimization invariants are violated. There is a slightly different continuation stub for each deopt point in the forEach implementation to ensure the correct side-effects, i.e. that the deopt of the builtin isn't programmatically observable. R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2926043005 Cr-Commit-Position: refs/heads/master@{#45798}
-
machenbach authored
Revert of [heap] Use larger marking steps during external allocation pressure (patchset #4 id:60001 of https://codereview.chromium.org/2927553003/ ) Reason for revert: Blocks the roll. Fails some layout tests: https://build.chromium.org/p/tryserver.v8/builders/v8_linux_blink_rel/builds/21757 STDERR: # Fatal error in ../../v8/src/heap/heap.cc, line 957 STDERR: # Check failed: 1.0 <= pressure (1 vs. -0.00503761). Original issue's description: > [heap] Use larger marking steps during external allocation pressure > > BUG=chromium:626082, chromium:728228 > > Review-Url: https://codereview.chromium.org/2927553003 > Cr-Commit-Position: refs/heads/master@{#45784} > Committed: https://chromium.googlesource.com/v8/v8/+/8d75644fc0ce1cee5d6eca42006f4c4aa89e9b86 TBR=ulan@chromium.org,hpayer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:626082, chromium:728228 Review-Url: https://codereview.chromium.org/2925333002 Cr-Commit-Position: refs/heads/master@{#45797}
-
bjaideep authored
Port d3371c23 Original Commit Message: DebugInfo was very closely tied to break point support: * It contained only information relevant to break points. * It was created and freed by break point implementation. * Existence of a DebugInfo on the shared function info implied existence of break points. This CL is a step towards making DebugInfo usable by other debugging functionality such as block coverage by decoupling it from break point support, which is now only one kind of information stored on the DebugInfo object. R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:6000 LOG=N Review-Url: https://codereview.chromium.org/2927813004 Cr-Commit-Position: refs/heads/master@{#45796}
-
bbudge authored
- Eliminates b1x4, b1x8, and b1x16 as distinct WASM types. - All vector comparisons return v128 type. - Eliminates b1xN and, or, xor, not. - Selects take a v128 mask vector and are now bit-wise. - Adds a new test for Select, where mask is non-canonical (not 0's and -1's). LOG=N BUG=v8:6020 Review-Url: https://codereview.chromium.org/2919203002 Cr-Commit-Position: refs/heads/master@{#45795}
-
bmeurer authored
This splits the monolithic Apply builtin into several smaller builtins, namely CallVargargs and ConstructVarargs, which accept a length and a FixedArray of elements and deal with the actual stack manipulation, and CallWithArrayLike / ConstructWithArrayLike that deal with getting the elements from the receiver (for Function.prototype.apply, Reflect.apply and Reflect.construct), which can now be written using the CSA. The idea is that these builtins can be reused by TurboFan directly in the future when we optimize apply better, and that we can also reuse the core logic in the handling of spread calls/constructs. R=petermarshall@chromium.org BUG=v8:4587,v8:5269 Review-Url: https://codereview.chromium.org/2930623002 Cr-Commit-Position: refs/heads/master@{#45794}
-
sampsong authored
Port 659e8f7b Original Commit Message: Instead of allocating and embedding certain heap numbers into the code during code assembly, emit dummies but record the allocation requests. Later then, in Assembler::GetCode, allocate the heap numbers and patch the code by replacing the dummies with the actual objects. The RelocInfos for the embedded objects are already recorded correctly when emitting the dummies. R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:6048 LOG=N Review-Url: https://codereview.chromium.org/2929843002 Cr-Commit-Position: refs/heads/master@{#45793}
-
Ulan Degenbaev authored
concurrent sweeping is disabled, which is not correct. MemoryAllocator: :CanFreeMemoryChunk returns true for the case when Change-Id: I560bac0275473445b52fba28b5e647b54f523a3a Reviewed-on: https://chromium-review.googlesource.com/528081Reviewed-by:
-
kschimpf authored
This CL takes advantage of the fact that StatsCounter is now local to the Counters class. This includes: 1) Method StatsTable::SetCreateHistogramFunction() was only called in one spot (in api.cc), which also called Counters::ResetHistograms() and Counters::InitializeHistorgram(). InitializeHistogram can be folded into Histogram.Reset(). 2) Since Histogram::Reset() now regenerats the histogram, we no longer need the field lookup_done_. Therefore there is no longer a race between updating ptr_ and lookup_done_, making the Histogram class thread safe. 3) Made the constructors of several classes private (except for class Counters), minimizing the scope that they are used. When the couldn't be moved, add comment that they were public only for test cases. 4) Removed the need for a mutex lock on StatsCounter::Reset(), since it is now guaranteed to only be called when StatsTable::SetCounterFunction() is called. BUG=v8:6361 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng Review-Url: https://codereview.chromium.org/2918703002 Cr-Commit-Position: refs/heads/master@{#45791}
-
Toon Verwaest authored
[builtins] Make sure to perform ToPrimitive(key, hint string) in hasOwnProperty even if the receiver is a smi. Bug: chromium:707580 Change-Id: I38f8740ac0df5d5e4e99808e4fa20bae88a23a11 Reviewed-on: https://chromium-review.googlesource.com/528077Reviewed-by:
-
Michael Starzinger authored
Both TurboFan and ThinStrings have been enabled by default for a while. This just disentangles the implication between those two flags and sets the --thin-strings individually. There is no technical reason for the implication. R=jkummerow@chromium.org Change-Id: I26e5357ffaf953de897c76d6edb8ac640bbeafd0 Reviewed-on: https://chromium-review.googlesource.com/528076Reviewed-by:
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4161431..9d6666d TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Change-Id: I3bddd9d99ea1840cce06dcb2c5b2bed33d2e7a7b Reviewed-on: https://chromium-review.googlesource.com/527576Reviewed-by:
-
Sathya Gunasekaran authored
Bug: v8:5717 Change-Id: I03579764656aa743bbc9bbf08e6affecd626d73d Reviewed-on: https://chromium-review.googlesource.com/527338Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45787}
-
Ross McIlroy authored
Add the ability for the typer to track whether a string could be the empty string. This is needed for typed lowering of JSStringConcat since we can't create cons string chain with the empty string in arbitrary positions. The ToPrimitiveToString bytecode handler is modified to collect feedback on whether it has ever seen the empty string, which is used by SpeculativeToPrimitiveToString to ensure that the output is non-empty (or depot) which will subsiquently be used to enable inline cons-string creation for the JSStringConcat operator in typed lowering in a subsiquent CL. BUG=v8:6243 Change-Id: I41b99b59798993f756aada8cff90fb137d65ea52 Reviewed-on: https://chromium-review.googlesource.com/522122 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#45786}
-
Michael Starzinger authored
The variant in question was intended to test Crankshaft, which is being deprecated. Note that the variants 'nooptimization' and 'fullcode' still test configuration where TurboFan is not active. R=machenbach@chromium.org BUG=v8:6408 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I587c3eee7ba511dfc270aab66b546d2532bc635f Reviewed-on: https://chromium-review.googlesource.com/528133Reviewed-by:
-
hpayer authored
BUG=chromium:626082, chromium:728228 Review-Url: https://codereview.chromium.org/2927553003 Cr-Commit-Position: refs/heads/master@{#45784}
-
Mythri authored
ThrowIfHole bytecodes were handled by introducing deopt points to check for a hole. To avoid deopt loops a hole check protector was used to generate control flow if there was a deopt due to a hole. However, the normal control flow version should be as fast as the deopt version in general. The deopt version could potentially consume less compile time but it may not be worth the complexity added. Hence simplifying it to only construct the control flow. Bug: v8:6383 Change-Id: Icace11f7a6e21e64e1cebd104496e3f559bc85f7 Reviewed-on: https://chromium-review.googlesource.com/525573Reviewed-by:
-
Michael Starzinger authored
This removes the last remaining dual implications between sets of flags. Support for this was originally added to support multiple subsequent calls to {SetFlagFromString} switching a set of flags on and off. Now that Chrome no longer relies on this behavior we can remove support for this entirely. Original CL: https://crrev.com/f774d8c56f00de92614886fc4cb541411eff7aa1 R=rmcilroy@chromium.org BUG=v8:6408 Change-Id: I5f9db8457c562c0b434ea7d6eca9941c76fe7d19 Reviewed-on: https://chromium-review.googlesource.com/527174Reviewed-by: -
Toon Verwaest authored
Don't treat new prototypes differently depending on how they become a prototype. This is work towards always keeping prototypes in slow-mode. Bug: v8:6471 Change-Id: I62de1018e21d91fda3a5da044615f32c718910b1 Reviewed-on: https://chromium-review.googlesource.com/526596Reviewed-by:
-
