- 14 Dec, 2017 1 commit
-
-
Igor Sheludko authored
Given that we already treat feedback vector as a source of truth for language mode of other store operations and given that the StoreGlobalIC dispatcher does not depend on the language more anymore, we can just combine these two bytecodes. Bug: v8:7206 Change-Id: I27f03f2102ff79ec20fa997eb18dde816f376b00 Reviewed-on: https://chromium-review.googlesource.com/823846Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#50102}
-
- 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}
-
- 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}
-
- 10 Apr, 2017 1 commit
-
-
Ross McIlroy authored
This relands commit d3e9aade. The original CL was reverted speculatively but didn't cause the buildbot failure. Original change's description: > [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator. > > Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi > literals in the BytecodeGenerator. This enables us to perform the > transformation for literals on either side for commutative operations, and > Avoids having to do the check on every bytecode in the peephole optimizer. > > In the process, adds Smi bytecode variants for all binary operations, adding > - MulSmi > - DivSmi > - ModSmi > - BitwiseXorSmi > - ShiftRightLogical > > BUG=v8:6194 > > Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219 > Reviewed-on: https://chromium-review.googlesource.com/466246 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44477} TBR=rmcilroy@chromium.org,machenbach@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,v8-reviews@googlegroups.com,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=v8:6194 Change-Id: I2ccaefa1ce58d3885f5c2648755985c06f25c1d8 Reviewed-on: https://chromium-review.googlesource.com/472746Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#44511}
-
- 07 Apr, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit d3e9aade. Reason for revert: Speculative for: https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/4449 Bisect points to this CL. Original change's description: > [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator. > > Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi > literals in the BytecodeGenerator. This enables us to perform the > transformation for literals on either side for commutative operations, and > Avoids having to do the check on every bytecode in the peephole optimizer. > > In the process, adds Smi bytecode variants for all binary operations, adding > - MulSmi > - DivSmi > - ModSmi > - BitwiseXorSmi > - ShiftRightLogical > > BUG=v8:6194 > > Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219 > Reviewed-on: https://chromium-review.googlesource.com/466246 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44477} TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,ishell@chromium.org,v8-reviews@googlegroups.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6194 Change-Id: If57dbdbe40be77804bf437463b855d3167e2d473 Reviewed-on: https://chromium-review.googlesource.com/471308Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44488}
-
Ross McIlroy authored
Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi literals in the BytecodeGenerator. This enables us to perform the transformation for literals on either side for commutative operations, and Avoids having to do the check on every bytecode in the peephole optimizer. In the process, adds Smi bytecode variants for all binary operations, adding - MulSmi - DivSmi - ModSmi - BitwiseXorSmi - ShiftRightLogical BUG=v8:6194 Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219 Reviewed-on: https://chromium-review.googlesource.com/466246 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#44477}
-
- 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}
-
- 16 Nov, 2016 1 commit
-
-
ishell authored
The reasons are: 1) The names dictionaries in the feedback metadata seems to consume a lot of memory and the idea didn't payoff. 2) The absence of a name parameter blocks data handlers support in LoadGlobalIC. This CL reverts a part of r37278 (https://codereview.chromium.org/2096653003/). BUG=chromium:576312, v8:5561 Review-Url: https://codereview.chromium.org/2510653002 Cr-Commit-Position: refs/heads/master@{#41046}
-
- 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}
-
- 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}
-
- 14 Sep, 2016 1 commit
-
-
bmeurer authored
Add a notion of "invocation count" to the baseline compilers, which increment a special slot in the TypeFeedbackVector for each invocation of a given function (the optimized code doesn't currently collect this information). Use this invocation count to relativize the call counts on the call sites within the function, so that the inlining heuristic has a view of relative importance of a call site rather than some absolute numbers with unclear meaning for the current function. Also apply the call site frequency as a factor to all frequencies in the inlinee by passing this to the graph builders so that the importance of a call site in an inlinee is relative to the topmost optimized function. Note that all functions that neither have literals nor need type feedback slots will share a single invocation count cell in the canonical empty type feedback vector, so their invocation count is meaningless, but that doesn't matter since we only use the invocation count to relativize call counts within the function, which we only have if we have at least one type feedback vector (the CallIC slot). See the design document for additional details on this change: https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8 BUG=v8:5267,v8:5372 R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2337123003 Cr-Commit-Position: refs/heads/master@{#39410}
-
- 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}
-
- 23 Aug, 2016 1 commit
-
-
epertoso authored
Drive-by fix: the order of parameters in the BinaryOpWithFeedback TurboFan code stubs now reflects the convention of having the context at the end. BUG=v8:5273 Review-Url: https://codereview.chromium.org/2263253002 Cr-Commit-Position: refs/heads/master@{#38832}
-
- 08 Aug, 2016 1 commit
-
-
mythria authored
Assign feedback slots in the type feedback vector for binary operations. Update bytecode-generator to use these slots and add them as an operand to binary operations. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2209633002 Cr-Commit-Position: refs/heads/master@{#38408}
-
- 05 Jul, 2016 1 commit
-
-
oth authored
Introduces fused bytecodes for fusing LdaSmi followed by a binary op bytecode. The chosen bytecodes are used frequently in Octane: AddSmi, SubSmi, BitwiseOrSmi, BitwiseAndSmi, ShiftLeftSmi, ShiftRightSmi. There are additional code stubs for these operations that are biased towards both the left hand and right hand operands being Smis. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2111923002 Cr-Commit-Position: refs/heads/master@{#37531}
-
- 27 Jun, 2016 1 commit
-
-
ishell authored
The global object can be loaded from the native context and the name can be loaded in the type feedback metadata. BUG=chromium:576312 Review-Url: https://codereview.chromium.org/2096653003 Cr-Commit-Position: refs/heads/master@{#37278}
-
- 25 May, 2016 1 commit
-
-
oth authored
This change introduces five fused bytecodes for common bytecode sequences on popular websites. These are LdrNamedProperty, LdrKeyedProperty, LdrGlobal, LdrContextSlot, and LdrUndefined. These load values into a destination register operand instead of the accumulator. They are emitted by the peephole optimizer. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1985753002 Cr-Commit-Position: refs/heads/master@{#36507}
-
- 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}
-