- 18 Oct, 2017 1 commit
-
-
Clemens Hammacher authored
This CL fixes all occurences that don't require special OWNER reviews, or can be reviewed by Michi. After this one, we should be able to reenable the readability/check cpplint check. R=mstarzinger@chromium.org Bug: v8:6837, v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ic81d68d5534eaa795b7197fed5c41ed158361d62 Reviewed-on: https://chromium-review.googlesource.com/721120 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48670}
-
- 05 Dec, 2016 1 commit
-
-
leszeks authored
Reorders the jump bytecodes so that the majority of jump checks can be implemented as range checks (rather than a list of comparisons that get compiled to a bunch of jumps). Review-Url: https://codereview.chromium.org/2537123002 Cr-Commit-Position: refs/heads/master@{#41498}
-
- 24 Oct, 2016 1 commit
-
-
rmcilroy authored
Modify the Bytecode Register Optimizer to be an independent component rather than part of the BytecodePipeline. This means the BytecodeArrayBuilder can explicitly call it with register operands when outputting a bytecode and the Bytecode Register Optimizer doesn't need to work out which operands are register operands. This also means we don't need to build BytecodeNodes for Ldar / Star / Mov bytecodes unless they are actually emitted by the optimizer. This change also modifies the way the BytecodeArrayBuilder converts operands to make use of the OperandTypes specified in bytecodes.h. This avoids having to individually convert operands to their raw output value before calling Output(...). BUG=v8:4280 Review-Url: https://codereview.chromium.org/2393683004 Cr-Commit-Position: refs/heads/master@{#40543}
-
- 22 Sep, 2016 2 commits
-
-
rmcilroy authored
This CL optimizes the code in BytecodeArrayBuilder and BytecodeArrayWriter by making the following main changes: - Move operand scale calculation out of BytecodeArrayWriter to the BytecodeNode constructor, where the decision on which operands are scalable can generally be statically decided by the compiler. - Move the maximum register calculation out of BytecodeArrayWriter and into BytecodeRegisterOptimizer (which is the only place outside BytecodeGenerator which updates which registers are used). This avoids the BytecodeArrayWriter needing to know the operand types of a node as it writes it. - Modify EmitBytecodes to use individual push_backs rather than building a buffer and calling insert, since this turns out to be faster. - Initialize BytecodeArrayWriter's bytecode vector by reserving 512 bytes, - Make common functions in Bytecodes constexpr so that they can be statically calculated by the compiler. - Move common functions and constructors in Bytecodes and BytecodeNode to the header so that they can be inlined. - Change large static switch statements in Bytecodes to const array lookups, and move to the header to allow inlining. I also took the opportunity to remove a number of unused helper functions, and rework some others for consistency. This reduces the percentage of time spent in making BytecodeArrays in CodeLoad from ~15% to ~11% according to perf. The CoadLoad score increase by around 2%. BUG=v8:4280 Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64 Review-Url: https://codereview.chromium.org/2351763002 Cr-Original-Commit-Position: refs/heads/master@{#39599} Cr-Commit-Position: refs/heads/master@{#39637}
-
hablich authored
Revert of [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. (patchset #6 id:200001 of https://codereview.chromium.org/2351763002/ ) Reason for revert: Prime suspect for roll blocker: https://codereview.chromium.org/2362503002/ Original issue's description: > [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. > > This CL optimizes the code in BytecodeArrayBuilder and > BytecodeArrayWriter by making the following main changes: > > - Move operand scale calculation out of BytecodeArrayWriter to the > BytecodeNode constructor, where the decision on which operands are > scalable can generally be statically decided by the compiler. > - Move the maximum register calculation out of BytecodeArrayWriter > and into BytecodeRegisterOptimizer (which is the only place outside > BytecodeGenerator which updates which registers are used). This > avoids the BytecodeArrayWriter needing to know the operand types > of a node as it writes it. > - Modify EmitBytecodes to use individual push_backs rather than > building a buffer and calling insert, since this turns out to be faster. > - Initialize BytecodeArrayWriter's bytecode vector by reserving 512 > bytes, > - Make common functions in Bytecodes constexpr so that they > can be statically calculated by the compiler. > - Move common functions and constructors in Bytecodes and > BytecodeNode to the header so that they can be inlined. > - Change large static switch statements in Bytecodes to const array > lookups, and move to the header to allow inlining. > > I also took the opportunity to remove a number of unused helper > functions, and rework some others for consistency. > > This reduces the percentage of time spent in making BytecodeArrays > in CodeLoad from ~15% to ~11% according to perf. The > CoadLoad score increase by around 2%. > > BUG=v8:4280 > > Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64 > Cr-Commit-Position: refs/heads/master@{#39599} TBR=mythria@chromium.org,leszeks@chromium.org,rmcilroy@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review-Url: https://codereview.chromium.org/2360193003 Cr-Commit-Position: refs/heads/master@{#39612}
-
- 21 Sep, 2016 1 commit
-
-
rmcilroy authored
This CL optimizes the code in BytecodeArrayBuilder and BytecodeArrayWriter by making the following main changes: - Move operand scale calculation out of BytecodeArrayWriter to the BytecodeNode constructor, where the decision on which operands are scalable can generally be statically decided by the compiler. - Move the maximum register calculation out of BytecodeArrayWriter and into BytecodeRegisterOptimizer (which is the only place outside BytecodeGenerator which updates which registers are used). This avoids the BytecodeArrayWriter needing to know the operand types of a node as it writes it. - Modify EmitBytecodes to use individual push_backs rather than building a buffer and calling insert, since this turns out to be faster. - Initialize BytecodeArrayWriter's bytecode vector by reserving 512 bytes, - Make common functions in Bytecodes constexpr so that they can be statically calculated by the compiler. - Move common functions and constructors in Bytecodes and BytecodeNode to the header so that they can be inlined. - Change large static switch statements in Bytecodes to const array lookups, and move to the header to allow inlining. I also took the opportunity to remove a number of unused helper functions, and rework some others for consistency. This reduces the percentage of time spent in making BytecodeArrays in CodeLoad from ~15% to ~11% according to perf. The CoadLoad score increase by around 2%. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2351763002 Cr-Commit-Position: refs/heads/master@{#39599}
-
- 09 Aug, 2016 1 commit
-
-
klaasb authored
Avoids the always generated Star bytecodes after ObjectLiteral. BUG=v4:4820 LOG=n Review-Url: https://codereview.chromium.org/2216023003 Cr-Commit-Position: refs/heads/master@{#38480}
-
- 15 Jul, 2016 1 commit
-
-
oth authored
> Original issue's description: > [interpreter] Reduce dependencies in bytecodes.{h,cc} > > This CL reduces the number of dependencies bytecodes.{h,cc} to facilitate > generating the bytecode peephole optimizer table during build. Specifically, > it avoids depending on v8_base. > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/4edebb1cd870ae6c1359ad54f83e618e185883b1 > Cr-Commit-Position: refs/heads/master@{#37715} BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2149093002 Cr-Commit-Position: refs/heads/master@{#37794}
-
- 14 Jul, 2016 1 commit
-
-
machenbach authored
Revert of [interpreter] Reduce dependencies in bytecodes.{h,cc} (patchset #8 id:140001 of https://codereview.chromium.org/2135273002/ ) Reason for revert: Breaks the roll, possibly win gn: https://codereview.chromium.org/2148863002/ Original issue's description: > [interpreter] Reduce dependencies in bytecodes.{h,cc} > > This CL reduces the number of dependencies bytecodes.{h,cc} to facilitate > generating the bytecode peephole optimizer table during build. Specifically, > it avoids depending on v8_base. > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/4edebb1cd870ae6c1359ad54f83e618e185883b1 > Cr-Commit-Position: refs/heads/master@{#37715} TBR=mstarzinger@chromium.org,rmcilroy@chromium.org,oth@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review-Url: https://codereview.chromium.org/2151693003 Cr-Commit-Position: refs/heads/master@{#37743}
-
- 13 Jul, 2016 1 commit
-
-
oth authored
This CL reduces the number of dependencies bytecodes.{h,cc} to facilitate generating the bytecode peephole optimizer table during build. Specifically, it avoids depending on v8_base. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2135273002 Cr-Commit-Position: refs/heads/master@{#37715}
-
- 28 Jun, 2016 1 commit
-
-
oth authored
Simplify bytecode array writing and remove some now unused bytecode traits definitions. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2100793003 Cr-Commit-Position: refs/heads/master@{#37321}
-
- 10 Jun, 2016 1 commit
-
-
oth authored
BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2041913002 Cr-Commit-Position: refs/heads/master@{#36885}
-
- 03 Jun, 2016 1 commit
-
-
Miran.Karic authored
A value in unittests/Bytecodes.DecodeBytecodeAndOperands was 16 bit instead of 8 bit. This was causing test to fail on big endian machines. BUG= Review-Url: https://codereview.chromium.org/2030063002 Cr-Commit-Position: refs/heads/master@{#36698}
-
- 01 Jun, 2016 1 commit
-
-
Miran.Karic authored
A few values were missing use of a macro causing test to fail on big endian machines. BUG= Review-Url: https://codereview.chromium.org/2024123002 Cr-Commit-Position: refs/heads/master@{#36645}
-
- 27 May, 2016 1 commit
-
-
oth authored
Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
-
- 12 May, 2016 1 commit
-
-
oth authored
This change introduces a pipeline for the final stages of bytecode generation. The peephole optimizer is made distinct from the BytecodeArrayBuilder. A new BytecodeArrayWriter is responsible for writing bytecode. It also keeps track of the maximum register seen and offers a potentially smaller frame size. R=rmcilroy@chromium.org LOG=N BUG=v8:4280 Review-Url: https://codereview.chromium.org/1947403002 Cr-Commit-Position: refs/heads/master@{#36220}
-
- 22 Apr, 2016 3 commits
-
-
mbrandy authored
The offset from fp to the register file is based on the frame size -- which is one slot larger when embedded constant pools are enabled. TEST=unittests/DecodeBytecodeAndOperands TBR=rmcilroy@chromium.org, bmeurer@chromium.org, oth@chromium.org, mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1906963002 Cr-Commit-Position: refs/heads/master@{#35735} Review URL: https://codereview.chromium.org/1909283003 Cr-Commit-Position: refs/heads/master@{#35737}
-
mbrandy authored
Revert of Fix interpreter unittest for embedded constant pools. (patchset #2 id:20001 of https://codereview.chromium.org/1906963002/ ) Reason for revert: Need to fix the #undef logic. Original issue's description: > Fix interpreter unittest for embedded constant pools. > > The offset from fp to the register file is based on the frame size > -- which is one slot larger when embedded constant pools are enabled. > > TEST=unittests/DecodeBytecodeAndOperands > R=rmcilroy@chromium.org, bmeurer@chromium.org, oth@chromium.org, mstarzinger@chromium.org > BUG= TBR=bmeurer@chromium.org,mstarzinger@chromium.org,oth@chromium.org,rmcilroy@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1909323003 Cr-Commit-Position: refs/heads/master@{#35736}
-
mbrandy authored
The offset from fp to the register file is based on the frame size -- which is one slot larger when embedded constant pools are enabled. TEST=unittests/DecodeBytecodeAndOperands R=rmcilroy@chromium.org, bmeurer@chromium.org, oth@chromium.org, mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1906963002 Cr-Commit-Position: refs/heads/master@{#35735}
-
- 19 Apr, 2016 1 commit
-
-
rmcilroy authored
Removes the register file machine register from the interpreter and replaces it will loads from the parent frame pointer. As part of this change the raw operand values for register values changes to enable the interpreter to keep using the operand value as the offset from the parent frame pointer. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1894063002 Cr-Commit-Position: refs/heads/master@{#35618}
-
- 13 Apr, 2016 1 commit
-
-
Miran.Karic authored
Operand values in Bytecodes.DecodeBytecodeAndOperands test are encoded in little endian format. The test calls Bytecodes::Decode function which reads the operands but the values are byte swapped on big endian machines. Added big endian encoded data which decodes correctly on BE machines. BUG= Review URL: https://codereview.chromium.org/1881423002 Cr-Commit-Position: refs/heads/master@{#35447}
-
- 06 Apr, 2016 1 commit
-
-
oth authored
Anotates bytecodes with a description of how each uses the accumulator. Validates annotations and uses of accumulator when generating bytecode handlers. Only prints the accumulator during tracing where used. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1852213002 Cr-Commit-Position: refs/heads/master@{#35281}
-
- 23 Mar, 2016 1 commit
-
-
oth authored
BUG=v8:4280,v8:4747 LOG=N Review URL: https://codereview.chromium.org/1825103002 Cr-Commit-Position: refs/heads/master@{#35024}
-
- 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}
-
- 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}
-
- 11 Feb, 2016 1 commit
-
-
mstarzinger authored
This replaces the bytecode in question with a runtime call within the bytecode stream. The tradeoff is to safe one bytecode opcode for more expensive encoding of lookup slot deletion. R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1690913002 Cr-Commit-Position: refs/heads/master@{#33907}
-
- 27 Jan, 2016 1 commit
-
-
oth authored
Introduces the concept of transfer direction to register operands. This enables the register translator to emit exactly the moves that a bytecode having it's register operands translated needs. BUG=v8:4280,v8:4675 LOG=N Review URL: https://codereview.chromium.org/1633153002 Cr-Commit-Position: refs/heads/master@{#33544}
-
- 26 Jan, 2016 1 commit
-
-
oth authored
This increases the size of register operands to be 16-bit. Not all bytecodes have wide register variants, so when they are needed a register translator will copy them into a small area reserved at the top of the 8-bit register range and these registers are supplied as arguments to the bytecode with 8-bit operands. This is non-intrusive for typical bytecode where the number of registers is less than 120. For bytecodes with wide register operands (above the window) their index needs to be translated to avoid the reserved translation window. Enables splay.js to run in Octane and a handful of mjsunit tests. BUG=v8:4280,v8:4675 LOG=NO Review URL: https://codereview.chromium.org/1613163002 Cr-Commit-Position: refs/heads/master@{#33516}
-
- 04 Jan, 2016 1 commit
-
-
oth authored
New bytecodes for making registers with indicies wider than 1-byte accessible. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1555713002 Cr-Commit-Position: refs/heads/master@{#33091}
-
- 28 Sep, 2015 1 commit
-
-
oth authored
The comparison operators and ToBoolean are implemented by calling into the runtime. There are new runtime methods are prefixed with Interpreter to make use case clear. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1369123002 Cr-Commit-Position: refs/heads/master@{#30983}
-
- 02 Sep, 2015 1 commit
-
-
oth authored
Add methods for converting parameter index to a register and vice-versa. Move Register class into bytecodes.h. Update Bytecodes::Decode to pretty print parameters. BUG=v8:4280 LOG=NO Review URL: https://codereview.chromium.org/1325983002 Cr-Commit-Position: refs/heads/master@{#30549}
-