- 06 Jul, 2017 1 commit
-
-
Sathya Gunasekaran authored
Bug: v8:5536 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icec1f77c6073e1e89210e71ad20044e09594209e Reviewed-on: https://chromium-review.googlesource.com/548987Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#46451}
-
- 26 Jun, 2017 2 commits
-
-
Michael Starzinger authored
This removes support for code-stub to tail-call into the runtime via the deoptimizer. The Hydrogen code-stubs would trigger a deopt in order to materialize a trampoline frame, which would then continue execution in a runtime function associated with each stub. This is no longer needed for code-stubs built with the CSA. R=jarin@chromium.org BUG=v8:6408 Change-Id: I1ff8dc03ac716200b28e962259a3e233aeda1234 Reviewed-on: https://chromium-review.googlesource.com/548375Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46223}
-
Peter Marshall authored
Bug: v8:6488 Change-Id: Icc1e8a71f32592f670f262eb588976c07af41a22 Reviewed-on: https://chromium-review.googlesource.com/541283Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#46197}
-
- 23 Jun, 2017 1 commit
-
-
Marja Hölttä authored
This removes the include from: assembler.h (moved Isolate::AddressId to globals.h / IsolateAddressId) counters.h (ditto) elements.h (trivial) keys.h (trivial + iwyu fixes) property.h (trivial) transitions.h (trivial) vm-state.h (trivial) heap/code-stats.h (trivial + drive-by iwyuing) BUG=v8:5294 Change-Id: I36b8c07d4edf4177f1a987a393569f5191167ed3 Reviewed-on: https://chromium-review.googlesource.com/532879Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#46176}
-
- 21 Jun, 2017 1 commit
-
-
bmeurer authored
Add a new JSConstructWithArrayLike operator that is backed by the ConstructWithArrayLike builtin (similar to what was done before for the JSCallWithArrayLike operator), and use that operator to optimize Reflect.construct inlining in TurboFan. This is handled uniformly with JSConstructWithSpread in the JSCallReducer. Also add missing test coverage for Reflect.construct in optimized code, especially for some interesting corner cases. R=petermarshall@chromium.org BUG=v8:4587,v8:5269 Review-Url: https://codereview.chromium.org/2949813002 Cr-Commit-Position: refs/heads/master@{#46087}
-
- 20 Jun, 2017 2 commits
-
-
bmeurer authored
Add a new JSCallWithArrayLike operator that is backed by the CallWithArrayLike builtin, and use that operator for both Function.prototype.apply and Reflect.apply inlining. Also unify the handling of JSCallWithArrayLike and JSCallWithSpread in the JSCallReducer to reduce the copy&paste overhead. Drive-by-fix: Add a lot of test coverage for Reflect.apply and Function.prototype.apply in optimized code, especially for some corner cases, which was missing so far. BUG=v8:4587,v8:5269 R=petermarshall@chromium.org Review-Url: https://codereview.chromium.org/2950773002 Cr-Commit-Position: refs/heads/master@{#46041}
-
Peter Marshall authored
We can remove a lot of native code and rely on CallOrConstructVarargs to do the stack manipulation for us. This will also take advantage of the fast-path for double arrays in CallOrConstructDoubleVarargs. We can also remove Runtime_SpreadIterableFixed because it isn't used anymore. We just call directly into spread_iterable from CSA. Bug: v8:6488, chromium:704966 Change-Id: I81a18281f062619851134fff7ce88471566ee3b5 Reviewed-on: https://chromium-review.googlesource.com/535615Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#46038}
-
- 19 Jun, 2017 1 commit
-
-
Leszek Swirski authored
For interpreted functions, use the optimized code slot in the feedback vector to store an optimization marker (optimize/in optimization queue) rather than changing the JSFunction's code object. Then, adapt the self-healing mechanism to also dispatch based on this optimization marker. Similarly, replace SFI marking with optimization marker checks in CompileLazy. This allows JSFunctions to share optimization information (replacing shared function marking) without leaking this information across native contexts. Non I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which generalises the old CompileOptimized/InOptimizationQueue builtins and also checks the same optimization marker as CompileLazy and InterpreterEntryTrampoline. This is a reland of https://chromium-review.googlesource.com/c/509716 Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe Reviewed-on: https://chromium-review.googlesource.com/535460Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45997}
-
- 14 Jun, 2017 1 commit
-
-
jgruber authored
This completes refactoring started in 0a355777. Bug: v8:6474 Change-Id: Ia2ea66e10e4f1d55551fe145f67f4021ae254b23 Reviewed-on: https://chromium-review.googlesource.com/532997 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#45934}
-
- 13 Jun, 2017 2 commits
-
-
Leszek Swirski authored
This reverts commit e39c9e02. Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561 Original change's description: > [compiler] Drive optimizations with feedback vector > > For interpreted functions, use the optimized code slot in the feedback vector > to store an optimization marker (optimize/in optimization queue) rather than > changing the JSFunction's code object. Then, adapt the self-healing mechanism > to also dispatch based on this optimization marker. Similarly, replace SFI > marking with optimization marker checks in CompileLazy. > > This allows JSFunctions to share optimization information (replacing shared > function marking) without leaking this information across native contexts. Non > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which > generalises the old CompileOptimized/InOptimizationQueue builtins and also > checks the same optimization marker as CompileLazy and > InterpreterEntryTrampoline. > > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae > Reviewed-on: https://chromium-review.googlesource.com/509716 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45901} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94 Reviewed-on: https://chromium-review.googlesource.com/532916Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45903}
-
Leszek Swirski authored
For interpreted functions, use the optimized code slot in the feedback vector to store an optimization marker (optimize/in optimization queue) rather than changing the JSFunction's code object. Then, adapt the self-healing mechanism to also dispatch based on this optimization marker. Similarly, replace SFI marking with optimization marker checks in CompileLazy. This allows JSFunctions to share optimization information (replacing shared function marking) without leaking this information across native contexts. Non I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which generalises the old CompileOptimized/InOptimizationQueue builtins and also checks the same optimization marker as CompileLazy and InterpreterEntryTrampoline. Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae Reviewed-on: https://chromium-review.googlesource.com/509716 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45901}
-
- 12 Jun, 2017 3 commits
-
-
Igor Sheludko authored
Don't use byte-width instructions when accessing |compiler_hints| field. This CL eases adding new bit fields to the compiler hints field. Bug: v8:6470 Change-Id: I7b07c1c8d0a11a303eebb5272d2846a5a84005f7 Reviewed-on: https://chromium-review.googlesource.com/529804 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#45860}
-
Igor Sheludko authored
Don't use byte-width instructions when accessing |compiler_hints| field (only FunctionKind bit field accesses are yet to be fixed). This CL eases adding new bit fields to the compiler hints field. Bug: v8:6470 Change-Id: Ibc2dfb42c0bf0df49fcb9e37c10fda789db4c3c8 Reviewed-on: https://chromium-review.googlesource.com/528120Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#45844}
-
Jakob Gruber authored
Callables for TF builtins are autogenerated and accessible through Builtins::CallableFor. This removes the manually written accessors from CodeFactory. Bug: v8:6474,v8:5737 Change-Id: I9d8dec97995471c1bb258147220c190bf72e5de8 Reviewed-on: https://chromium-review.googlesource.com/530745Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45839}
-
- 09 Jun, 2017 1 commit
-
-
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}
-
- 08 Jun, 2017 1 commit
-
-
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}
-
- 07 Jun, 2017 1 commit
-
-
danno authored
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. Review-Url: https://codereview.chromium.org/2803853005 Cr-Commit-Position: refs/heads/master@{#45764}
-
- 31 May, 2017 1 commit
-
-
jgruber authored
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 Review-Url: https://codereview.chromium.org/2909893002 Cr-Commit-Position: refs/heads/master@{#45640}
-
- 23 May, 2017 2 commits
-
-
machenbach authored
Revert of [es2015] Precompute the descriptive string for symbols. (patchset #3 id:40001 of https://codereview.chromium.org/2900703002/ ) Reason for revert: Speculative revert for: https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/8901 Original issue's description: > [es2015] Precompute the descriptive string for symbols. > > Previously the String constructor and the Symbol.prototype.toString > methods had to compute the descriptive string for a Symbol on the fly, > which can produce a lot of garbage when this happens a lot, i.e. when > the String representation of a Symbol is used often. Now instead of > doing this on-demand we can just do it upfront when creating the Symbol. > > That way we also ensure that we won't throw an exception when accessing > the descriptive string of a Symbol, due to potential String length > overflow, but have the exception during Symbol creation upfront, which > is a lot less surprising behavior. > > BUG=v8:6278,v8:6344,v8:6350 > TBR=mlippautz@chromium.org > R=ishell@chromium.org > > Review-Url: https://codereview.chromium.org/2900703002 > Cr-Commit-Position: refs/heads/master@{#45479} > Committed: https://chromium.googlesource.com/v8/v8/+/e87573822e1c0c041c03f2b60599b0ab9256422f TBR=ishell@chromium.org,mlippautz@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6278,v8:6344,v8:6350 Review-Url: https://codereview.chromium.org/2903533002 Cr-Commit-Position: refs/heads/master@{#45483}
-
bmeurer authored
Previously the String constructor and the Symbol.prototype.toString methods had to compute the descriptive string for a Symbol on the fly, which can produce a lot of garbage when this happens a lot, i.e. when the String representation of a Symbol is used often. Now instead of doing this on-demand we can just do it upfront when creating the Symbol. That way we also ensure that we won't throw an exception when accessing the descriptive string of a Symbol, due to potential String length overflow, but have the exception during Symbol creation upfront, which is a lot less surprising behavior. BUG=v8:6278,v8:6344,v8:6350 TBR=mlippautz@chromium.org R=ishell@chromium.org Review-Url: https://codereview.chromium.org/2900703002 Cr-Commit-Position: refs/heads/master@{#45479}
-
- 18 May, 2017 1 commit
-
-
bmeurer authored
We already had an optimization to turn Function.prototype.apply with arguments object, i.e. function foo() { return bar.apply(this, arguments); } into a special operator JSCallForwardVarargs, which avoids the allocation and deconstruction of the arguments object, but just passes along the incoming parameters. We can do the same for rest parameters and spread calls/constructs, i.e. class A extends B { constructor(...args) { super(...args); } } or function foo(...args) { return bar(1, 2, 3, ...args); } where we basically pass along the parameters (plus maybe additional statically known parameters). For this, we introduce a new JSConstructForwardVarargs operator and generalize the CallForwardVarargs builtins that are backing this. BUG=v8:6407,v8:6278,v8:6344 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2890023004 Cr-Commit-Position: refs/heads/master@{#45388}
-
- 16 May, 2017 1 commit
-
-
Ross McIlroy authored
Now that the optimized code hangs off the feedback vector, it is possible to check whether a function has optimized code available every time it's called in the interpreter entry trampoline. If optimized code exists, the interpreter entry trampoline 'self-heals' the closure to point to the optimized code and links the closure into the optimized code list. BUG=v8:6246 Change-Id: I53b095db2a75ae4824c8195faf8649d766c86118 Reviewed-on: https://chromium-review.googlesource.com/501967Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45328}
-
- 15 May, 2017 1 commit
-
-
Ross McIlroy authored
BUG=chromium:721078,v8:6246 Change-Id: I10f20d9cc2c7cabff8a3fba02aff351fcecc0ce2 Reviewed-on: https://chromium-review.googlesource.com/505611Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45304}
-
- 12 May, 2017 1 commit
-
-
ivica.bogosavljevic authored
Add Miran Karic and Dusan Simicic Remove Paul Lind, Gergely Kis, Akos Palfi, Balasz Kilvady and Dusan Milosavljevic NOTRY=true Review-Url: https://codereview.chromium.org/2881493003 Cr-Commit-Position: refs/heads/master@{#45273}
-
- 11 May, 2017 1 commit
-
-
dusan.simicic authored
This patch fixes regresion introduced in CL: https://chromium-review.googlesource.com/c/489525/ ldr instruction is unaligned load on MIPS and it is not available in MIPS64r6 architecture. BUG= Review-Url: https://codereview.chromium.org/2873873005 Cr-Commit-Position: refs/heads/master@{#45257}
-
- 10 May, 2017 2 commits
-
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246,chromium:718891 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6 Reviewed-on: https://chromium-review.googlesource.com/500134Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45234}
-
Tobias Tebbi authored
[turbofan] [builtins] Unify construct builtins for JS functions and classes and add inlining and deoptimizer support BUG=v8:6180 R=mstarzinger@chromium.org Change-Id: Iac5782a0f6b0ff92293421656d907073cfc3f5dd Reviewed-on: https://chromium-review.googlesource.com/489525 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45232}
-
- 08 May, 2017 2 commits
-
-
Ross McIlroy authored
This reverts commit 662aa425. Reason for revert: Crashing on Canary BUG=chromium:718891 Original change's description: > Reland: [TypeFeedbackVector] Store optimized code in the vector > > Since the feedback vector is itself a native context structure, why > not store optimized code for a function in there rather than in > a map from native context to code? This allows us to get rid of > the optimized code map in the SharedFunctionInfo, saving a pointer, > and making lookup of any optimized code quicker. > > Original patch by Michael Stanton <mvstanton@chromium.org> > > BUG=v8:6246 > TBR=yangguo@chromium.org,ulan@chromium.org > > Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327 > Reviewed-on: https://chromium-review.googlesource.com/494487 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45084} TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=v8:6246 Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82 Reviewed-on: https://chromium-review.googlesource.com/498633Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45174}
-
Ross McIlroy authored
This reverts commit ec619cbd. Reason for revert: Crashing on Canary BUG=chromium:718891 Original change's description: > [Interpreter] Transition JSFunctions to call optimized code when possible. > > Now that the optimized code hangs off the feedback vector, it is possible > to check whether a function has optimized code available every time it's > called in the interpreter entry trampoline. If optimized code exists, the > interpreter entry trampoline 'self-heals' the closure to point to the > optimized code and links the closure into the optimized code list. > > BUG=v8:6246 > > Change-Id: If1bd7c555bb0551bfe04b36baa6bcf949604717e > Reviewed-on: https://chromium-review.googlesource.com/488026 > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45103} TBR=rmcilroy@chromium.org,mvstanton@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=v8:6246 Change-Id: Ibda719be90fddf1d116c03a2a0c3018bcbe76018 Reviewed-on: https://chromium-review.googlesource.com/498632Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45169}
-
- 04 May, 2017 2 commits
-
-
Ross McIlroy authored
Now that the optimized code hangs off the feedback vector, it is possible to check whether a function has optimized code available every time it's called in the interpreter entry trampoline. If optimized code exists, the interpreter entry trampoline 'self-heals' the closure to point to the optimized code and links the closure into the optimized code list. BUG=v8:6246 Change-Id: If1bd7c555bb0551bfe04b36baa6bcf949604717e Reviewed-on: https://chromium-review.googlesource.com/488026Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45103}
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327 Reviewed-on: https://chromium-review.googlesource.com/494487Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45084}
-
- 02 May, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit c5ad9c6d. Reason for revert: Fails on gc stress: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/12661 Original change's description: > [TypeFeedbackVector] Store optimized code in the vector > > Since the feedback vector is itself a native context structure, why > not store optimized code for a function in there rather than in > a map from native context to code? This allows us to get rid of > the optimized code map in the SharedFunctionInfo, saving a pointer, > and making lookup of any optimized code quicker. > > Original patch by Michael Stanton <mvstanton@chromium.org> > > BUG=v8:6246 > > Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5 > Reviewed-on: https://chromium-review.googlesource.com/476891 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45022} TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,jarin@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6246 Change-Id: I9cd5735b03898cae6ae7adea0f19d32fceb31619 Reviewed-on: https://chromium-review.googlesource.com/493287Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#45027}
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246 Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5 Reviewed-on: https://chromium-review.googlesource.com/476891 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45022}
-
- 20 Apr, 2017 2 commits
-
-
sreten.kovacevic authored
Fix 6ee0b6ce Fix wrong register usage for MIPS ports TEST=mjsunit/regress/regress-5638b BUG= Review-Url: https://codereview.chromium.org/2831733004 Cr-Commit-Position: refs/heads/master@{#44749}
-
Ilija.Pavlovic authored
For MIPS64, many load/store operations from/to memory emit more then one instruction. This is the reason for moving them from assembler to macro-assembler. TEST= BUG= Review-Url: https://codereview.chromium.org/2829073002 Cr-Commit-Position: refs/heads/master@{#44746}
-
- 18 Apr, 2017 1 commit
-
-
predrag.rudic authored
Fix 751e8935 commit Fix typo in implementation BUG= Review-Url: https://codereview.chromium.org/2816733004 Cr-Commit-Position: refs/heads/master@{#44676}
-
- 12 Apr, 2017 1 commit
-
-
Sathya Gunasekaran authored
This change mirrors the semantics for derived class constructors. This change doesn't affect non class constructors. This change could potentially break web compat. More details: https://github.com/tc39/ecma262/pull/469 Bug=v8:5536 Change-Id: I519599949523733332d0b35e4f8d9ecb01cac495 Reviewed-on: https://chromium-review.googlesource.com/461225Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#44594}
-
- 11 Apr, 2017 2 commits
-
-
Leszek Swirski authored
Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
-
Michael Achenbach authored
This reverts commit 751e8935. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
-
- 10 Apr, 2017 1 commit
-
-
Leszek Swirski authored
Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc Reviewed-on: https://chromium-review.googlesource.com/463287 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44530}
-