- 12 Aug, 2016 1 commit
-
-
yangguo authored
R=jgruber@chromium.org, mstarzinger@chromium.org BUG=v8:5265 Review-Url: https://codereview.chromium.org/2246483002 Cr-Commit-Position: refs/heads/master@{#38621}
-
- 28 Jul, 2016 3 commits
-
-
mstarzinger authored
R=rmcilroy@chromium.org TEST=mjsunit/ignition/osr-from-generator BUG=v8:4764 Review-Url: https://codereview.chromium.org/2185973004 Cr-Commit-Position: refs/heads/master@{#38144}
-
oth authored
BUG=chromium:629792 LOG=N Review-Url: https://codereview.chromium.org/2185123003 Cr-Commit-Position: refs/heads/master@{#38140}
-
mstarzinger authored
R=neis@chromium.org TEST=mjsunit/ignition/osr-from-generator BUG=v8:4764 Review-Url: https://codereview.chromium.org/2188723005 Cr-Commit-Position: refs/heads/master@{#38125}
-
- 26 Jul, 2016 3 commits
-
-
mstarzinger authored
Reland of [interpreter] Add explicit OSR polling bytecode. (patchset #1 id:1 of https://codereview.chromium.org/2184553003/ ) Reason for revert: Fix has been landed. Original issue's description: > Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ ) > > Reason for revert: > Bunch of breakages. Maybe bad interaction with https://chromium.googlesource.com/v8/v8/+/e520e5da5550f0d1a975e87d6e66a2edecbb0c8e ? > > E.g.: > https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607 > > Original issue's description: > > [interpreter] Add explicit OSR polling bytecode. > > > > This adds an explicit {OsrPoll} bytecode into every loop header which > > triggers on-stack replacement when armed. Note that each such bytecode > > stores the static loop depths as an operand, and hence can be armed for > > specific loop depths. > > > > This also adds builtin code that triggers OSR compilation and switches > > execution over to optimized code in case compilation succeeds. In case > > compilation fails, the bytecode dispatch just continues unhindered. > > > > R=rmcilroy@chromium.org > > TEST=mjsunit/ignition/osr-from-bytecode > > BUG=v8:4764 > > > > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458 > > Cr-Commit-Position: refs/heads/master@{#38043} > > TBR=rmcilroy@chromium.org,mstarzinger@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:4764 > > Committed: https://crrev.com/439aa2c6d708bfd95db725bd6f97c4c49bbc51fc > Cr-Commit-Position: refs/heads/master@{#38044} TBR=rmcilroy@chromium.org,machenbach@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2184713002 Cr-Commit-Position: refs/heads/master@{#38056}
-
machenbach authored
Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ ) Reason for revert: Bunch of breakages. Maybe bad interaction with https://chromium.googlesource.com/v8/v8/+/e520e5da5550f0d1a975e87d6e66a2edecbb0c8e ? E.g.: https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607 Original issue's description: > [interpreter] Add explicit OSR polling bytecode. > > This adds an explicit {OsrPoll} bytecode into every loop header which > triggers on-stack replacement when armed. Note that each such bytecode > stores the static loop depths as an operand, and hence can be armed for > specific loop depths. > > This also adds builtin code that triggers OSR compilation and switches > execution over to optimized code in case compilation succeeds. In case > compilation fails, the bytecode dispatch just continues unhindered. > > R=rmcilroy@chromium.org > TEST=mjsunit/ignition/osr-from-bytecode > BUG=v8:4764 > > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458 > Cr-Commit-Position: refs/heads/master@{#38043} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4764 Review-Url: https://codereview.chromium.org/2184553003 Cr-Commit-Position: refs/heads/master@{#38044}
-
mstarzinger authored
This adds an explicit {OsrPoll} bytecode into every loop header which triggers on-stack replacement when armed. Note that each such bytecode stores the static loop depths as an operand, and hence can be armed for specific loop depths. This also adds builtin code that triggers OSR compilation and switches execution over to optimized code in case compilation succeeds. In case compilation fails, the bytecode dispatch just continues unhindered. R=rmcilroy@chromium.org TEST=mjsunit/ignition/osr-from-bytecode BUG=v8:4764 Review-Url: https://codereview.chromium.org/2172233002 Cr-Commit-Position: refs/heads/master@{#38043}
-
- 01 Jun, 2016 2 commits
-
-
rmcilroy authored
Eliminating dead code in the bytecode array builder doesn't play nice with the register elimination optimizer. We should move it to it's own stage in the optimization pipeline, however doing so would require refactoring of how we deal with jumps, so for now just remove the dead code elimination optimization. BUG=chromium:616064 Review-Url: https://codereview.chromium.org/2030583002 Cr-Commit-Position: refs/heads/master@{#36660}
-
rmcilroy authored
GenerateSmiToDouble on ia32 assumes that it is called from a JSFrame and can restore the context from the StandardFrameConstants::kContextObject. In the case of the interpreter it is called from a interpreter handler stub frame which doesn't push the context onto it's frame. Instead, push and pop esi to explicitly restore it correctly. BUG=chromium:612386 Review-Url: https://codereview.chromium.org/2011313003 Cr-Commit-Position: refs/heads/master@{#36649}
-
- 23 May, 2016 1 commit
-
-
oth authored
The original peephole optimizer logic in the BytecodeArrayBuilder did not respect source positions as it was written before there were bytecode source positions. This led to some minor differences to FCG and was problematic when combined with pending bytecode optimizations. This change makes the new peephole optimizer fully respect source positions. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1998203002 Cr-Commit-Position: refs/heads/master@{#36439}
-
- 10 May, 2016 1 commit
-
-
mstarzinger authored
This implements declaration of lookup slots for variables and functions within optimized code. Such a declaration only appears with top-level eval code, which we only recently started handling in TurboFan. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/1962723002 Cr-Commit-Position: refs/heads/master@{#36125}
-
- 06 May, 2016 1 commit
-
-
rmcilroy authored
Some tests which fail with '--ignition --turbo --turbo-from-bytecode' pass with just '--ignition'. Unskip these tests. Also group other tests with related bugs. BUG=v8:4680 LOG=N Review-Url: https://codereview.chromium.org/1944413002 Cr-Commit-Position: refs/heads/master@{#36083}
-
- 27 Apr, 2016 1 commit
-
-
ssanfilippo authored
This commit introduces IgnitionStatisticsExtension, which provides methods for accessing Ignition statistics and counters from JavaScript. The extension is registered when FLAG_ignition and FLAG_trace_ignition_dispatches are both enabled. For the moment, the only exposed function is getIgnitionDispatchCounters(), which allows to retrieve Ignition dispatch counters as a JavaScript object. BUG=v8:4899 LOG=N Review URL: https://codereview.chromium.org/1899133004 Cr-Commit-Position: refs/heads/master@{#35816}
-
- 01 Apr, 2016 1 commit
-
-
mythria authored
Handles bytecodeArray Objects when verifying the heap and also when collecting code statistics. The changes include: 1. BytecodeArrays could be a part of the large object space. When verifying the large object space we should also allow BytecodeArray objects. 2. Adds support for BytecodeArrays when collecting code statistics. BUG=v8:4280,chromium:599001 LOG=N Review URL: https://codereview.chromium.org/1850443006 Cr-Commit-Position: refs/heads/master@{#35202}
-
- 31 Mar, 2016 2 commits
-
-
mythria authored
In the earlier implementation of GenerateDoubleToObject the context is loaded from the parent's frame. rsi is clobbered because it is used to store kHoleNan constnat. It is not always safe to peek at the parents frame. Bytecode handlers have TypedFrame and the type of frame is stored at FP + 1. GenerateDoubleToObject expects context to be store at that place. In the current implementation rsi is pushed onto the stack and is popped when exiting this function. BUG=v8:4280,chromium:597565 LOG=N Review URL: https://codereview.chromium.org/1848473002 Cr-Commit-Position: refs/heads/master@{#35163}
-
oth authored
Fixes a stale DCHECK and a memory leak in tracing output. LOG=N BUG=v8:4280 TBR=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1844023003 Cr-Commit-Position: refs/heads/master@{#35161}
-
- 21 Mar, 2016 1 commit
-
-
oth authored
This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
-
- 16 Mar, 2016 1 commit
-
-
mythria authored
We need to pop the context to correct level on return as well. This was incorrectly removed in this cl: https://codereview.chromium.org/1768123002/. For example when we have a try-catch-finally block and catch does a return, the return does not happen immediately. It should execute finally block before it returns. Return statement should pop the context to the correct level as expected by finally block. BUG=594369,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1796893002 Cr-Commit-Position: refs/heads/master@{#34822}
-
- 15 Mar, 2016 1 commit
-
-
yangguo authored
We may not emit bytecode for the evaluation of the to-be-returned expression. In that case we cannot set two return positions for a return statement (one before and one after the expression evaluation). This sets the interpreter apart from full-codegen. Make sure that we always have the second of the two return positions. Note that we end up with separate test cases for ignition and FCG. R=rmcilroy@chromium.org, vogelheim@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1801473003 Cr-Commit-Position: refs/heads/master@{#34771}
-
- 02 Mar, 2016 1 commit
-
-
yangguo authored
R=mythria@chromium.org, rmcilroy@chromium.org BUG=v8:4689 LOG=N Review URL: https://codereview.chromium.org/1759673002 Cr-Commit-Position: refs/heads/master@{#34434}
-
- 23 Feb, 2016 1 commit
-
-
yangguo authored
R=mcilroy@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1723803004 Cr-Commit-Position: refs/heads/master@{#34210}
-
- 22 Feb, 2016 1 commit
-
-
yangguo authored
R=mstarzinger@chromium.org, rmcilroy@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1703453002 Cr-Commit-Position: refs/heads/master@{#34190}
-
- 05 Feb, 2016 1 commit
-
-
yangguo authored
R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1668863002 Cr-Commit-Position: refs/heads/master@{#33775}
-
- 04 Feb, 2016 3 commits
-
-
yangguo authored
R=mstarzinger@chromium.org, rmcilroy@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1667073002 Cr-Commit-Position: refs/heads/master@{#33739}
-
yangguo authored
This is to avoid polluting fuzzer seeds with the --ignition flag until we figure out something better. TBR=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1661333002 Cr-Commit-Position: refs/heads/master@{#33729}
-
yangguo authored
This change adds the basic infrastructure to record source positions for bytecode. R=rmcilroy@chromium.org, vogelheim@chromium.org BUG=v8:4960 LOG=N Review URL: https://codereview.chromium.org/1662983002 Cr-Commit-Position: refs/heads/master@{#33726}
-
- 28 Jan, 2016 1 commit
-
-
yangguo authored
This change adds AbstractCode, which can be either Code or BytecodeArray, and adds methods to calculate source position based on that. Also cleans up to use code offsets instead of raw PC where possible, and consistently uses the offset from instruction start (as opposed to code object start). R=rmcilroy@chromium.org, vogelheim@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1618343002 Cr-Commit-Position: refs/heads/master@{#33579}
-