- 25 Jan, 2019 1 commit
-
-
Leszek Swirski authored
Declare Variables with a name and position, rather than by passing through a VariableProxy. This allows us to not create dummy proxies for things like function declarations, and allows us to consider those declarations unused. As a side-effect, we also have to check if a variable is unused in the bytecode generator (as it will no longer be allocated), and we end up skip generating code/SFIs for dead variables/functions. Change-Id: I4c2c872473f23e124f9456b4b92f87159658f8e0 Reviewed-on: https://chromium-review.googlesource.com/c/1414916 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#59088}
-
- 03 May, 2018 1 commit
-
-
Toon Verwaest authored
There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
-
- 27 Jul, 2017 1 commit
-
-
Leszek Swirski authored
Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
-
- 25 Jul, 2017 1 commit
-
-
Leszek Swirski authored
Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
-
- 17 Jul, 2017 1 commit
-
-
Leszek Swirski authored
This reverts commit a2fcdc7c. Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126) Original change's description: > [runtime] Move profiler ticks from SFI to feedback vector > > Instead of counting profiler ticks on the shared function info (which is > shared between native contexts), count them on the feedback vector > (which is not). This allows us to continue pushing optimization > decisions off the SFI, onto the feedback vector. > > Note that a side-effect of this is that ICs don't have to walk the stack > to reset profiler ticks, as they can access the feedback vector directly > from their feedback nexus. > > Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f > Reviewed-on: https://chromium-review.googlesource.com/544888 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46411} TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8 Reviewed-on: https://chromium-review.googlesource.com/574227 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46702}
-
- 14 Jul, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
-
- 05 Jul, 2017 1 commit
-
-
Leszek Swirski authored
Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
-
- 06 Jun, 2017 1 commit
-
-
Mythri authored
Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole / ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks. In the bytecode-graph builder they are handled by introducing a deopt point instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant bytecodes are removed since they are no longer required. Bug: v8:4280, v8:6383 Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1 Reviewed-on: https://chromium-review.googlesource.com/509613 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45720}
-
- 30 May, 2017 1 commit
-
-
Aleksey Kozyatinskiy authored
This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. Benefits (see test for details): - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. TBR=dgozman@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org,devtools-reviews@chromium.org,v8-reviews@googlegroups.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:5909 Change-Id: Ie84fa79afeed09e28cf8478ba610a0cfbfdfc294 Reviewed-on: https://chromium-review.googlesource.com/518116 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45598}
-
- 29 May, 2017 1 commit
-
-
Michael Achenbach authored
This reverts commit 7a9cc704. Reason for revert: Changes layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/15882 This is about: inspector/sources/debugger/source-frame-inline-breakpoint-decorations.html Original change's description: > [inspector] moved var initialization break location before init expression > > This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. > Benefits (see test for details): > - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), > - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. > > Bug: v8:5909 > Change-Id: I039d911903a2826c9859710a63ab0462c992e11b > Reviewed-on: https://chromium-review.googlesource.com/513926 > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45530} TBR=dgozman@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:5909 Change-Id: Ibf84401e8050d3c84db219d983de2c6bba0f697f Reviewed-on: https://chromium-review.googlesource.com/518102Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#45547}
-
- 25 May, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. Benefits (see test for details): - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. Bug: v8:5909 Change-Id: I039d911903a2826c9859710a63ab0462c992e11b Reviewed-on: https://chromium-review.googlesource.com/513926 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#45530}
-
- 10 May, 2017 1 commit
-
-
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}
-
- 08 May, 2017 1 commit
-
-
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}
-
- 04 May, 2017 1 commit
-
-
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}
-
- 07 Feb, 2017 3 commits
-
-
hablich authored
Reland of Thread maybe-assigned through the bytecodes. (patchset #1 id:1 of https://codereview.chromium.org/2680923003/ ) Reason for revert: False alarm, bot hiccup Original issue's description: > Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ ) > > Reason for revert: > needed for properly reverting https://chromium.googlesource.com/v8/v8/+/f3ae5ccf57690d8c2d87c4fe1d10b103ad6a4ab3 > > Original issue's description: > > Thread maybe-assigned through the bytecodes. > > > > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot > > bytecodes, which are emitted when reading from never-assigned context slot. > > > > There is a subtlety here: the slot are not immutable, the meaning is > > actually undefined-or-hole-or-immutable. > > > > Review-Url: https://codereview.chromium.org/2655733003 > > Cr-Commit-Position: refs/heads/master@{#43000} > > Committed: https://chromium.googlesource.com/v8/v8/+/17c2dd388697da626224c371c8181d20d2016d82 > > TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > > Review-Url: https://codereview.chromium.org/2680923003 > Cr-Commit-Position: refs/heads/master@{#43011} > Committed: https://chromium.googlesource.com/v8/v8/+/ece4e54a31ac76ee9c450270d65270562db716e1 TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2679953003 Cr-Commit-Position: refs/heads/master@{#43012}
-
hablich authored
Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ ) Reason for revert: needed for properly reverting https://chromium.googlesource.com/v8/v8/+/f3ae5ccf57690d8c2d87c4fe1d10b103ad6a4ab3 Original issue's description: > Thread maybe-assigned through the bytecodes. > > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot > bytecodes, which are emitted when reading from never-assigned context slot. > > There is a subtlety here: the slot are not immutable, the meaning is > actually undefined-or-hole-or-immutable. > > Review-Url: https://codereview.chromium.org/2655733003 > Cr-Commit-Position: refs/heads/master@{#43000} > Committed: https://chromium.googlesource.com/v8/v8/+/17c2dd388697da626224c371c8181d20d2016d82 TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2680923003 Cr-Commit-Position: refs/heads/master@{#43011}
-
jarin authored
This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot bytecodes, which are emitted when reading from never-assigned context slot. There is a subtlety here: the slot are not immutable, the meaning is actually undefined-or-hole-or-immutable. Review-Url: https://codereview.chromium.org/2655733003 Cr-Commit-Position: refs/heads/master@{#43000}
-
- 25 Jan, 2017 1 commit
-
-
leszeks authored
Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
-
- 09 Jan, 2017 1 commit
-
-
mvstanton authored
This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
-
- 22 Dec, 2016 1 commit
-
-
hablich authored
Revert of [TypeFeedbackVector] Root literal arrays in function literals slots (patchset #11 id:370001 of https://codereview.chromium.org/2504153002/ ) Reason for revert: Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/ Original issue's description: > [TypeFeedbackVector] Root literal arrays in function literals slots > > Literal arrays and feedback vectors for a function can be garbage > collected if we don't have a rooted closure for the function, which > happens often. It's expensive to come back from this (recreating > boilerplates and gathering feedback again), and the cost is > disproportionate if the function was inlined into optimized code. > > To guard against losing these arrays when we need them, we'll now > create literal arrays when creating the feedback vector for the outer > closure, and root them strongly in that vector. > > BUG=v8:5456 > > Review-Url: https://codereview.chromium.org/2504153002 > Cr-Commit-Position: refs/heads/master@{#41893} > Committed: https://chromium.googlesource.com/v8/v8/+/93df094081f04c629c3df2e40318de90ce5e0fb9 TBR=bmeurer@chromium.org,mlippautz@chromium.org,mvstanton@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5456 Review-Url: https://codereview.chromium.org/2597163002 Cr-Commit-Position: refs/heads/master@{#41917}
-
- 21 Dec, 2016 1 commit
-
-
mvstanton authored
Literal arrays and feedback vectors for a function can be garbage collected if we don't have a rooted closure for the function, which happens often. It's expensive to come back from this (recreating boilerplates and gathering feedback again), and the cost is disproportionate if the function was inlined into optimized code. To guard against losing these arrays when we need them, we'll now create literal arrays when creating the feedback vector for the outer closure, and root them strongly in that vector. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2504153002 Cr-Commit-Position: refs/heads/master@{#41893}
-
- 10 Nov, 2016 1 commit
-
-
rmcilroy authored
We seem to get some small wins from avoiding the Ldr bytecodes, probably due to reduced icache pressure since there are less bytecode handlers. Replace the Ldr bytecodes with Star lookahead inlined into the Lda versions. Also fixes IsAccumulatorLoadWithoutEffects to include LdaContextSlot and LdaCurrentContextSlot BUG=v8:4280 Review-Url: https://codereview.chromium.org/2489513005 Cr-Commit-Position: refs/heads/master@{#40883}
-
- 28 Oct, 2016 1 commit
-
-
leszeks authored
The majority of context slot accesses are to the local context (current context register and depth 0), so this adds bytecodes to optimise for that case. This cuts down bytecode size by roughly 1% (measured on Octane and Top25). Review-Url: https://codereview.chromium.org/2459513002 Cr-Commit-Position: refs/heads/master@{#40641}
-
- 20 Oct, 2016 1 commit
-
-
adamk authored
Move hole check logic from full-codegen into scope analysis, and store the "needs hole check" bit on VariableProxy. This makes it easy to re-use in any backend: it will be trivial to extend the use of this logic in, e.g., full-codegen variable stores. While changing the signatures of the variable loading/storing methods in Ignition, I took the liberty of replacing the verb "Visit" with "Build", since these are not part of AST visiting. BUG=v8:5460 Review-Url: https://chromiumcodereview.appspot.com/2411873004 Cr-Commit-Position: refs/heads/master@{#40479}
-
- 04 Oct, 2016 1 commit
-
-
neis authored
This removes the execute_ flag, which was always the negation of top_level_. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2390163003 Cr-Commit-Position: refs/heads/master@{#39961}
-
- 13 Sep, 2016 1 commit
-
-
leszeks authored
Moves the context chain search loop out of generated bytecode, and into the (Lda|Ldr|Sda)ContextSlot handler, by passing the context depth in as an additional operand. This should decrease the bytecode size and increase performance for deep context chain searches, at the cost of slightly increasing bytecode size for shallow context access. Review-Url: https://codereview.chromium.org/2336643002 Cr-Commit-Position: refs/heads/master@{#39378}
-
- 06 Sep, 2016 1 commit
-
-
leszeks authored
For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
-
- 03 Aug, 2016 1 commit
-
-
klaasb authored
Add a new bytecode to create a function context. The handler inlines FastNewFunctionContextStub. BUG=v8:4280 LOG=n Review-Url: https://codereview.chromium.org/2187523002 Cr-Commit-Position: refs/heads/master@{#38301}
-
- 30 Jun, 2016 1 commit
-
-
rmcilroy authored
BUG=v8:4280 Review-Url: https://codereview.chromium.org/2113613002 Cr-Commit-Position: refs/heads/master@{#37453}
-
- 09 Jun, 2016 1 commit
-
-
oth authored
With this change the bytecode array builder only emits expression positions for bytecodes that can throw. This allows more peephole optimization opportunities and results in smaller code. BUG=v8:4280,chromium:615979 LOG=N Review-Url: https://codereview.chromium.org/2038323002 Cr-Commit-Position: refs/heads/master@{#36863}
-
- 11 May, 2016 1 commit
-
-
oth authored
Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
-
- 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}
-
- 25 Feb, 2016 1 commit
-
-
ssanfilippo authored
Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
-