- 11 Sep, 2017 5 commits
-
-
Georg Neis authored
BigInt is a new primitive type of arbitrary precision integers, proposed in https://tc39.github.io/proposal-bigint. This CL introduces a corresponding instance type, map, and C++ class to V8 and adds BigInt support to a few operations (see the test file). Much more is to come. Also, the concrete representation of BigInts is not yet fixed, currently a BigInt is simply a wrapped Smi. Bug: v8:6791 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45 Reviewed-on: https://chromium-review.googlesource.com/657022Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#47956}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: If0554f01068fb76228e85cfe120630eda86de41d Reviewed-on: https://chromium-review.googlesource.com/659997Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47945}
-
Benedikt Meurer authored
The Typer put the wrong type on String#index and String#lastIndexOf builtins, with an off by one on the upper bound. Bug: chromium:762874 Change-Id: Ia4c29bc2e8e1c85b6a7ae0b99f8aaabf839a5932 Reviewed-on: https://chromium-review.googlesource.com/660000Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47942}
-
Benedikt Meurer authored
TurboFan wasn't able to inline calls to Array.prototype.push which didn't have exactly one parameter. This was a rather artifical limitation and was mostly due to the way the MaybeGrowFastElements operator was implemented (which was not ideal by itself). Refactoring this a bit, allows us to inline the operation in general, independent of the number of values to push. Array#push with multiple parameters is used quite a lot inside Ember (as discovered by Apple, i.e. https://bugs.webkit.org/show_bug.cgi?id=175823) and is also dominating the Six-Speed/SpreadLiterals/ES5 benchmark (see https://twitter.com/SpiderMonkeyJS/status/906528938452832257 from the SpiderMonkey folks). The micro-benchmark mentioned in the tracking bug (v8:6808) improves from arrayPush0: 2422 ms. arrayPush1: 2567 ms. arrayPush2: 4092 ms. arrayPush3: 4308 ms. to arrayPush0: 798 ms. arrayPush1: 2563 ms. arrayPush2: 2623 ms. arrayPush3: 2773 ms. with this change, effectively removing the odd 50-60% performance cliff that was associated with going from one parameter to two or more. Bug: v8:2229, v8:6808 Change-Id: Iffe4c1233903c04c3dc2062aad39d99769c8ab57 Reviewed-on: https://chromium-review.googlesource.com/657582Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47940}
-
Jaroslav Sevcik authored
[turbofan] Reland^3 "Polymorphic inlining - try merge map check dispatch with function call dispatch." This reverts commit ae28e0cf. Bug: chromium:758096 Change-Id: I6541bd1ba46cd5dfb942ed3f3d382e047fb1f3e6 Reviewed-on: https://chromium-review.googlesource.com/657401Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47934}
-
- 09 Sep, 2017 1 commit
-
-
Anisha Rohra authored
Port 9e995e12 Port 408f252b Up to now, each architecture defined all Register types as structs, with lots of redundancy. An often found comment noted that they cannot be classes due to initialization order problems. As these problems are gone with C++11 constexpr constants, I now tried making Registers classes again. All register types now inherit from RegisterBase, which provides a default set of methods and named constructors (like ::from_code, code(), bit(), is_valid(), ...). This design allows to guarantee an interesting property: Each register is either valid, or it's the no_reg register. There are no other invalid registers. This is guaranteed statically by the constexpr constructor, and dynamically by ::from_code. I decided to disallow the default constructor completely, so instead of "Register reg;" you now need "Register reg = no_reg;". This makes explicit how the Register is initialized. I did this change to the x64, ia32, arm, arm64, mips and mips64 ports. Overall, code got much more compact and more safe. In theory, it should also increase performance (since the is_valid() check is simpler), but this is probably not measurable. R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2e87efc8790290c64fd6c0a2d093326710b30ed3 Reviewed-on: https://chromium-review.googlesource.com/658065Reviewed-by:
Jaideep Bajwa <bjaideep@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47933}
-
- 08 Sep, 2017 5 commits
-
-
Michael Starzinger authored
R=mvstanton@chromium.org BUG=v8:6409 Change-Id: I9252055a395287381d2646fedc59c8c376333694 Reviewed-on: https://chromium-review.googlesource.com/652469Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47927}
-
Clemens Hammacher authored
This is a cleanup for a presubmit check that might get enabled soon: https://chromium-review.googlesource.com/c/v8/v8/+/657104 R=ahaas@chromium.org CC=mstarzinger@chromium.org Change-Id: Id431f2d4e8fcbb88a777b63e3fb136fa8ceac70a Reviewed-on: https://chromium-review.googlesource.com/657400 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47926}
-
Jaroslav Sevcik authored
The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
-
Benedikt Meurer authored
Add support to the JSCallReducer to recognize JSConstruct nodes where the target is the Object constructor, and reduce them to JSCreate nodes if either (a) no value is passed to the Object constructor, or (b) the target and new.target are definitely not identical, by checking whether both target and new.target are different HeapConstants (if they are not, then the JSCreateLowering will not be able to do a lot with the JSCreate anyways). This should cover the relevant cases for subclassing appropriately. It fixes the 3-4x slowdown on the micro-benchmark mentioned in the linked bug, baseNoExtends: 752 ms. baseExtendsObject: 752 ms. baseExtendsViaFactory: 751 ms. and thus removes the performance cliff. R=jarin@chromium.org Bug: v8:6801 Change-Id: Id265fd1399302a67b5790a6d0156679920c58bdd Reviewed-on: https://chromium-review.googlesource.com/657019Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47913}
-
Aseem Garg authored
This is revert of commit aee1e1fb with the fix for A1 and N6 jetstream failure. R=bradnelson@chromium.org,mtrofin@chromium.org,clemensh@chromium.org Bug: chromium:750828 Change-Id: Id38896af51315f76a0667ace32c77a2ba7287eec Reviewed-on: https://chromium-review.googlesource.com/607092 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#47910}
-
- 07 Sep, 2017 6 commits
-
-
Benedikt Meurer authored
Bug: v8:6772 Tbr: jarin@chromium.org Change-Id: I48b21fbdec42d4b1c10800913f7fa222a5509a8d Reviewed-on: https://chromium-review.googlesource.com/654873Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47897}
-
Michael Starzinger authored
R=marja@chromium.org Change-Id: I7e1b471c425a28d77100ce3cda34511393b31365 Reviewed-on: https://chromium-review.googlesource.com/654901Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47892}
-
Clemens Hammacher authored
Use operator== and operator!= instead. Implemented for x64, ia32, arm, arm64, mips and mips64. R=mstarzinger@chromium.org,ishell@chromium.org,jgruber@chromium.org Change-Id: Iad0f03f7f442709dcaa12d6a49a8bc4b03b9cdae Reviewed-on: https://chromium-review.googlesource.com/654857 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47889}
-
Juliana Franco authored
Given that we no longer need to iterate over lists of optimized JS functions (c.f. https://chromium-review.googlesource.com/c/v8/v8/+/647596), we can remove this field. Thus saving the size of one pointer per function. Bug: v8:6637 Change-Id: If77951f2eddba33ba350fa9ddf03a4edb3f7c7d8 Reviewed-on: https://chromium-review.googlesource.com/652373Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> Cr-Commit-Position: refs/heads/master@{#47875}
-
Ross McIlroy authored
JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
-
Benedikt Meurer authored
Introduce NodeProperties::NoObservableSideEffectBetween to check if there's any observable side effect between two nodes in the effect chain. Use this to guard the insertion of potentially redundant map checks in the lowering of Object.prototype.hasOwnProperty and keyed accesses within a for..in loop. This gives another boost on the for..in performance front. Bug: v8:6702 Change-Id: I68133f14ad388a1a7422714319c9b323d5cf8bc4 Reviewed-on: https://chromium-review.googlesource.com/654640Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#47869}
-
- 06 Sep, 2017 6 commits
-
-
Jaideep Bajwa authored
R=joransiu@ca.ibm.com, jyan@ca.ibm.com BUG= LOG=N Change-Id: I353f953b6b2d9c20ebd9d141b33da47761f3e43b Reviewed-on: https://chromium-review.googlesource.com/653808Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47860}
-
Mostyn Bramley-Moore authored
This macro is defined all over the place, and often causes macro redefinition errors in jumbo builds. Let's make sure all such instances created in source files are #undef'ed. Candidate files found with: grep -wL '#undef TRACE' $(git grep -wl '#define TRACE' -- '*.cc') While we're at it, let's undef all macros defined in these files. Bug: chromium:746958 Change-Id: I639ca2b141f908457d1b2601cd6d5827dee0ead0 Reviewed-on: https://chromium-review.googlesource.com/652476Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com> Cr-Commit-Position: refs/heads/master@{#47859}
-
Clemens Hammacher authored
Up to now, each architecture defined all Register types as structs, with lots of redundancy. An often found comment noted that they cannot be classes due to initialization order problems. As these problems are gone with C++11 constexpr constants, I now tried making Registers classes again. All register types now inherit from RegisterBase, which provides a default set of methods and named constructors (like ::from_code, code(), bit(), is_valid(), ...). This design allows to guarantee an interesting property: Each register is either valid, or it's the no_reg register. There are no other invalid registers. This is guaranteed statically by the constexpr constructor, and dynamically by ::from_code. I decided to disallow the default constructor completely, so instead of "Register reg;" you now need "Register reg = no_reg;". This makes explicit how the Register is initialized. I did this change to the x64, ia32, arm, arm64, mips and mips64 ports. Overall, code got much more compact and more safe. In theory, it should also increase performance (since the is_valid() check is simpler), but this is probably not measurable. R=mstarzinger@chromium.org Change-Id: I5ccfa4050daf4e146a557970e9d37fd3d2788d4a Reviewed-on: https://chromium-review.googlesource.com/650927Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47847}
-
sreten.kovacevic authored
MIPS[64]: Port: `[Atomics] Make Atomics.exchange a builtin using TF` and `[Atomics] Make Atomics.compareExchange a builtin using TF` Port 301c1237 and 82b5c8c9 Implemented exchange and compareExchange atomics. Bug: Change-Id: I11a0d3d608ecf809c7947dd560884c6451dcdb3c Reviewed-on: https://chromium-review.googlesource.com/649186Reviewed-by:
Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Cr-Commit-Position: refs/heads/master@{#47846}
-
Jaroslav Sevcik authored
Revert "[turbofan] Reland^2 "Polymorphic inlining - try merge map check dispatch with function call dispatch."" This reverts commit 8cf4aafc. Reason for revert: Likely crashes Canary. https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Mac%27%20AND%20product.version%3D%2763.0.3207.0%27%20AND%20custom_data.ChromeCrashProto.channel%3D%27canary%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27renderer%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27v8%3A%3Ainternal%3A%3Acompiler%3A%3AGraphTrimmer%3A%3ATrimGraph%27&sql_dialect=dremelsql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&unnest= Original change's description: > [turbofan] Reland^2 "Polymorphic inlining - try merge map check dispatch with function call dispatch." > > This reverts commit e26e6d88. > > Bug: chromium:758096 > Change-Id: I1d8ecda995c93c84a9a3c24da041fdb730dbd3b2 > Reviewed-on: https://chromium-review.googlesource.com/628169 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47812} TBR=jarin@chromium.org,tebbi@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:758096 Change-Id: I96b62d08efa25ac1ead30e08401919d42a20ca1b Reviewed-on: https://chromium-review.googlesource.com/652370Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47845}
-
Anisha Rohra authored
Port f0acede9 This CL removes the weak-list of JS functions from the context and all the code that iterares over it. This list was being used mainly during deoptimization (for code unlinking) and during garbage collection. Removing it will improve performance of programs that create many closures and trigger many scavenge GC cycles. No extra work is required during garbage collection. However, given that we no longer unlink code from JS functions during deoptimization, we leave it as it is, and on its next activation we check whether the mark_for_deoptimization bit of that code is set, and if it is, than we unlink it and jump to lazy compiled code. This check happens in the prologue of every code object. We needed to change/remove the cctests that used to check something on this list. R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I8007a837d43b6a339789cfd727e81ad7f4ac3ae1 Reviewed-on: https://chromium-review.googlesource.com/651891Reviewed-by:
Jaideep Bajwa <bjaideep@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47840}
-
- 05 Sep, 2017 10 commits
-
-
Jakob Kummerow authored
Bug: v8:1569 Change-Id: I84317ce1ac145b69caa26452721f71aac88f219e Reviewed-on: https://chromium-review.googlesource.com/636699 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#47839}
-
Jakob Kummerow authored
Only the error cases of overwriting readonly properties need the language_mode to decide whether to throw or be silent. Reading it from the feedback vector's metadata (just like the C++ code in ic.cc does) removes the need to duplicate each stub for each language_mode ("StoreIC" + "StoreICStrict" etc.). Change-Id: Ic0c67f9d40ca36c65e41b4f162b2ab70d155e549 Reviewed-on: https://chromium-review.googlesource.com/647373Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47836}
-
Jakob Kummerow authored
AFAICT this doesn't currently change observable behavior, but should be fixed nonetheless. Change-Id: I1dce90ae5bcad39d7d54dddd2559bd7f7ccbb095 Reviewed-on: https://chromium-review.googlesource.com/648354Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47835}
-
Jaideep Bajwa authored
Fix register corruption and save constant pool register. R=joransiu@ca.ibm.com, jyan@ca.ibm.com BUG= LOG=N Change-Id: I278b7f9a60e10c5347cdfba52432837f68c82836 Reviewed-on: https://chromium-review.googlesource.com/649812 Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47832}
-
Adam Klein authored
Change-Id: I891ff57b7a3a47e3371269b123705cdf6391499b Reviewed-on: https://chromium-review.googlesource.com/648513Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47830}
-
Jaroslav Sevcik authored
Checked number is not automatically truncating to float64. Bug: chromium:761892 Change-Id: I34bd5d7867cd38b2be18cd39a810605603f515e2 Reviewed-on: https://chromium-review.googlesource.com/649513 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47824}
-
Jaroslav Sevcik authored
Bug: Change-Id: Iedd273d517e2ee2e548a5e9732689114800e6128 Reviewed-on: https://chromium-review.googlesource.com/649749Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47822}
-
Jaroslav Sevcik authored
[turbofan] Reland^2 "Polymorphic inlining - try merge map check dispatch with function call dispatch." This reverts commit e26e6d88. Bug: chromium:758096 Change-Id: I1d8ecda995c93c84a9a3c24da041fdb730dbd3b2 Reviewed-on: https://chromium-review.googlesource.com/628169Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47812}
-
Jaroslav Sevcik authored
Bug: v8:5267 Change-Id: If2a36a53016f683b9eddb6cba76e3328cd69f98b Reviewed-on: https://chromium-review.googlesource.com/649847Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47809}
-
Juliana Franco authored
This CL removes the weak-list of JS functions from the context and all the code that iterares over it. This list was being used mainly during deoptimization (for code unlinking) and during garbage collection. Removing it will improve performance of programs that create many closures and trigger many scavenge GC cycles. No extra work is required during garbage collection. However, given that we no longer unlink code from JS functions during deoptimization, we leave it as it is, and on its next activation we check whether the mark_for_deoptimization bit of that code is set, and if it is, than we unlink it and jump to lazy compiled code. This check happens in the prologue of every code object. We needed to change/remove the cctests that used to check something on this list. Working in x64, ia32, arm64, arm, mips64 and mips. Bug: v8:6637 Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24 TBR: mstarzinger@chromium.org Reviewed-on: https://chromium-review.googlesource.com/647596 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47808}
-
- 04 Sep, 2017 7 commits
-
-
Clemens Hammacher authored
R=mstarzinger@chromium.org Bug: chromium:746958 Change-Id: Id0afb27e88944a64bf301533fa164668294f8446 Reviewed-on: https://chromium-review.googlesource.com/648978 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47802}
-
Michael Starzinger authored
This adds support for the backing store of mapped arguments objects to escape analysis. It also unifies two simplified operators representing allocations of these backing stores into a single {NewArgumentsElements} operator and threads through the "mapped count" to the deoptimizer. R=tebbi@chromium.org Change-Id: I1864e29a5703348597b7b2e41deaf5fab73e2c93 Reviewed-on: https://chromium-review.googlesource.com/643208 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47800}
-
Albert Mingkun Yang authored
In kArchSaveCallerRegisters, PushCallerSaved alone alters stack pointer without informing `frame_access_state`. This commit compensate the inconsistency by manually increasing the delta after pushing registers. This affects systems (currently only ARM64) using stack pointer for accessing variables stored on stack. Bug: chromium:749486 Change-Id: Ic6da3826323d4fb1c545ade3d4d2cd4d1fed1843 Reviewed-on: https://chromium-review.googlesource.com/633606 Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47797}
-
Jaroslav Sevcik authored
We encode the reachability/liveness in the placement. After we prepare use counts, the kUnknown placement means that the noe is unreachable. Bug: v8:5267 Change-Id: Iad27159508f0aefb812b6394a257055f789fbe13 Reviewed-on: https://chromium-review.googlesource.com/646247 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47795}
-
Michael Achenbach authored
This reverts commit 84c2dfce. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876 Original change's description: > Remove weak-list of optimized JS functions. > > This CL removes the weak-list of JS functions from the context > and all the code that iterares over it. This list was being used > mainly during deoptimization (for code unlinking) and during > garbage collection. Removing it will improve performance of > programs that create many closures and trigger many scavenge GC > cycles. > > No extra work is required during garbage collection. However, > given that we no longer unlink code from JS functions during > deoptimization, we leave it as it is, and on its next activation > we check whether the mark_for_deoptimization bit of that code is > set, and if it is, than we unlink it and jump to lazy compiled > code. This check happens in the prologue of every code object. > > We needed to change/remove the cctests that used to check > something on this list. > > Working in x64, ia32, arm64, arm, mips64 and mips. > > Bug: v8:6637 > Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3 > Reviewed-on: https://chromium-review.googlesource.com/600427 > Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47790} TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6637 Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47792}
-
Juliana Franco authored
This CL removes the weak-list of JS functions from the context and all the code that iterares over it. This list was being used mainly during deoptimization (for code unlinking) and during garbage collection. Removing it will improve performance of programs that create many closures and trigger many scavenge GC cycles. No extra work is required during garbage collection. However, given that we no longer unlink code from JS functions during deoptimization, we leave it as it is, and on its next activation we check whether the mark_for_deoptimization bit of that code is set, and if it is, than we unlink it and jump to lazy compiled code. This check happens in the prologue of every code object. We needed to change/remove the cctests that used to check something on this list. Working in x64, ia32, arm64, arm, mips64 and mips. Bug: v8:6637 Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3 Reviewed-on: https://chromium-review.googlesource.com/600427 Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47790}
-
Clemens Hammacher authored
This allows to reuse this logic in the wasm baseline compiler to determine the location of our parameters. R=mstarzinger@chromium.org CC=titzer@chromium.org Bug: v8:6600 Change-Id: I86e4d425d1c8aa35f0f722d311a2bd830b951d0a Reviewed-on: https://chromium-review.googlesource.com/647628Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47784}
-