- 02 Mar, 2020 1 commit
-
-
Leszek Swirski authored
Remove OffThreadHandle, HandleOrOffThreadHandle, and HandleFor, and make the OffThreadIsolate allocate "real" Handles. Rather than using the main-thread Isolate's handle scopes, these off-thread Handles are backed by a Zone, which is tied to the lifetime of the nearest OffThreadHandleScope. Eventually, we'll likely want to merge the implementation of OffThreadHandleScope and HandleScope, but currently the latter is too tightly coupled to the main thread to do so. Bug: chromium:1011762 Change-Id: I2a6361931fe3f90a7bef4cc28ee42155fa8d062f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071865Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66516}
-
- 20 Feb, 2020 1 commit
-
-
Leszek Swirski authored
Bug: chromium:1011762 Change-Id: I58284d50acaf349ed5c56654972e2c2bcece1ec3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2061550 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66378}
-
- 10 Feb, 2020 1 commit
-
-
Santiago Aboy Solanes authored
FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206}
-
- 02 Sep, 2019 1 commit
-
-
Dan Elphick authored
If a bytecode mismatch occurs, the original and new bytecode are now printed along with the position of the bytecode mismatch. Bug: v8:8510 Change-Id: Ia3b016fb4e0edde46944533a6a768499b20678d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774722 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63500}
-
- 23 Aug, 2019 1 commit
-
-
Dan Elphick authored
This changes Compiler::CollectSourcePositions to skip finalization of the BytecodeArray, constant table, handler table, ScopeInfos as well as internalization of Ast values since only the source position table is used and the others will be collected soon after by the GC. It will also now avoid recompiling inner functions that would otherwise be eagerly compiled. BytecodeArrayWriter::ToBytecodeArray has been changed to never populate the source_position_table. Bug: v8:8510 Change-Id: I2db2f2da6b48fde11f17a20d017c1a54c0a34fc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763538 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63365}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 28 Feb, 2019 3 commits
-
-
Leszek Swirski authored
This is a reland of 35269f77 Switches on an expression that unconditionally throws would have all their case statements dead, causing a DCHECK error in the SwitchBuilder. This fixes up the DCHECK to allow dead labels. Original change's description: > [ignition] Skip binding dead labels > > BytecodeLabels for forward jumps may create a dead basic block if their > corresponding jump was elided (due to it dead code elimination). We can > avoid generating such dead basic blocks by skipping the label bind when > no corresponding jump has been observed. This works because all jumps > except JumpLoop are forward jumps, so we only have to special case one > Bind for loop headers to bind unconditionally. > > Since Binds are now conditional on a jump existing, we can no longer rely > on using Bind to get the current offset (e.g. at the beginning of a try > block). Instead, we now expose the current offset in the bytecode array > writer. Conveniently, this means that we can be a bit smarter about basic > blocks around these statements. > > As a drive-by, remove the unused Bind(target,label) function. > > Bug: chromium:934166 > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3 > Reviewed-on: https://chromium-review.googlesource.com/c/1488763 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59942} TBR=rmcilroy@chromium.org Bug: chromium:934166 Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4 Reviewed-on: https://chromium-review.googlesource.com/c/1494535Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59948}
-
Sigurd Schneider authored
This reverts commit 35269f77. Reason for revert: Fuzzer unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Fuzzer/29792 Original change's description: > [ignition] Skip binding dead labels > > BytecodeLabels for forward jumps may create a dead basic block if their > corresponding jump was elided (due to it dead code elimination). We can > avoid generating such dead basic blocks by skipping the label bind when > no corresponding jump has been observed. This works because all jumps > except JumpLoop are forward jumps, so we only have to special case one > Bind for loop headers to bind unconditionally. > > Since Binds are now conditional on a jump existing, we can no longer rely > on using Bind to get the current offset (e.g. at the beginning of a try > block). Instead, we now expose the current offset in the bytecode array > writer. Conveniently, this means that we can be a bit smarter about basic > blocks around these statements. > > As a drive-by, remove the unused Bind(target,label) function. > > Bug: chromium:934166 > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3 > Reviewed-on: https://chromium-review.googlesource.com/c/1488763 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59942} TBR=rmcilroy@chromium.org,leszeks@chromium.org Change-Id: I8118e54e0afa5e08b0a0a874c952f8a01f1c3242 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:934166 Reviewed-on: https://chromium-review.googlesource.com/c/1494534Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59947}
-
Leszek Swirski authored
BytecodeLabels for forward jumps may create a dead basic block if their corresponding jump was elided (due to it dead code elimination). We can avoid generating such dead basic blocks by skipping the label bind when no corresponding jump has been observed. This works because all jumps except JumpLoop are forward jumps, so we only have to special case one Bind for loop headers to bind unconditionally. Since Binds are now conditional on a jump existing, we can no longer rely on using Bind to get the current offset (e.g. at the beginning of a try block). Instead, we now expose the current offset in the bytecode array writer. Conveniently, this means that we can be a bit smarter about basic blocks around these statements. As a drive-by, remove the unused Bind(target,label) function. Bug: chromium:934166 Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3 Reviewed-on: https://chromium-review.googlesource.com/c/1488763 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#59942}
-
- 08 Nov, 2018 1 commit
-
-
Leszek Swirski authored
The Ignition statement list visitor will skip the rest of the statements in the list if it hits a jump statement (like a return or break), as the rest of the code in the list can be considered dead. return; dead_call(); // skipped However, since this is at an AST node level, it does not take into account condition shortcutting: if(2.2) return; dead_call(); // not skipped There is also a second dead code elimination in Ignition compilation, at the bytecode array writer level, where a bytecodes are not emitted if an "exit" bytecode (Return, Jump, or a few others) has been written, until the next basic block starts (i.e. a Bind). This can cause an issue with statements that resurrect the bytecode array writer part-way through their visit. An example is try-catch statements, which save the context to a register, and then Bind to start the try region. For the case: if (2.2) return; try { // try statement not skipped ... } the bytecode writer is called with OutputReturn() // exit bytecode seen OutputMove(<context>, r1) // not emitted Bind(&try_begin) // starts new basic block // try body So, the try is emitted, but without saving the context to a register. This means that the liveness analysis sees the read of that register (as the output liveness of throwing bytecodes), but does not have a write to the register, which means that the liveness escapes. This patch fixes this by using the bytecode array writer dead-code elimination (i.e. "exit bytecode seen") to inform the statement list visitor, so that in this example the try statement is not visited at all. Bug: chromium:902395 Change-Id: Ieb8e46a4318df3edbac0ae17235e0ce8fba12ee3 Reviewed-on: https://chromium-review.googlesource.com/c/1322951Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#57350}
-
- 27 Feb, 2018 1 commit
-
-
Michael Starzinger authored
This changes the encoding of the {HandlerTable} from an array of Smi values to a byte array. It allows embedding of said array into the instruction stream of {Code} objects (similar to how safepoint tables work). For interpreted bytecode the table is attached as a {ByteArray} to the bytecode. The advantage of this approach is a more compact encoding and also the ability to move such tables easily off the GC'ed heap if needed (as is done for WebAssembly code for example). R=jarin@chromium.org Change-Id: I3320415dff69b3d1053825bda0d667a28232bf6d Reviewed-on: https://chromium-review.googlesource.com/934642 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51589}
-
- 20 Oct, 2017 1 commit
-
-
Michael Starzinger authored
This allocates and populates potential source position table before the underlying {Code} objects is allocated. It essentially makes the field holding said table immutable after allocation. R=verwaest@chromium.org BUG=v8:6792 Change-Id: If35462688a1b502f28ae84f73b82b5df5005735f Reviewed-on: https://chromium-review.googlesource.com/727895Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48781}
-
- 19 Oct, 2017 1 commit
-
-
Mostyn Bramley-Moore authored
This makes jumbo_file_merge_limit=50 work again. Bug: chromium:770684 Change-Id: I5db6566da876d71ea6ba50ff03b7652074b0a35f Reviewed-on: https://chromium-review.googlesource.com/725818Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com> Cr-Commit-Position: refs/heads/master@{#48728}
-
- 27 Jun, 2017 1 commit
-
-
Leszek Swirski authored
This reverts commit 87f71769. Reason for revert: Performance regressions https://chromeperf.appspot.com/group_report?rev=46185 Original change's description: > [ignition] Merge bytecode array builder and writer > > Move bytecode array writing logic into the array builder, allowing us to > remove the bytecode array writer and bytecode node, and convert runtime > operand writing to compile-time bytecode operand writing using the > information statically known at compile time. > > Bug: v8:6474 > Change-Id: I210cd9897fd41293745614e4a253c7c251dfffc9 > Reviewed-on: https://chromium-review.googlesource.com/533055 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46183} TBR=rmcilroy@chromium.org,leszeks@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6474 Bug: chromium:736646 Change-Id: I00287b2bbbb8efa5a3141bc9c2906f91a7d33e51 Reviewed-on: https://chromium-review.googlesource.com/549319Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46235}
-
- 23 Jun, 2017 1 commit
-
-
Leszek Swirski authored
Move bytecode array writing logic into the array builder, allowing us to remove the bytecode array writer and bytecode node, and convert runtime operand writing to compile-time bytecode operand writing using the information statically known at compile time. Bug: v8:6474 Change-Id: I210cd9897fd41293745614e4a253c7c251dfffc9 Reviewed-on: https://chromium-review.googlesource.com/533055 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46183}
-
- 15 May, 2017 1 commit
-
-
Leszek Swirski authored
Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
-
- 12 Apr, 2017 1 commit
-
-
Ross McIlroy authored
The BytecodePipeline is no longer used by any optimizers, so remove it and connect the BytecodeArrayBuilder directly to the BytecodeWriter. Also remove some functions from BytecodeNode which are no longer used. BUG=v8:6194 Change-Id: Id2ec94ff1d4db41b108a778100459283fbb2256c Reviewed-on: https://chromium-review.googlesource.com/471528Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#44619}
-
- 11 Apr, 2017 2 commits
-
-
Ross McIlroy authored
Move dead bytecode elimination from a seperate bytecode pipeline optimizer into the BytecodeArrayWriter. This removes the last bytecode pipeline optimizer, which means we can remove the Bytecode pipeline which, which should increase compile speed. BUG=v8:6194 Change-Id: I47fb3c3463b2b8a92e02cf7a6b608683fcfa5261 Reviewed-on: https://chromium-review.googlesource.com/471407 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44568}
-
Ross McIlroy authored
Moves the logic for eliding non-effectful accumulator load elision from the peephole optimizer to the BytecodeArrayWriter. BUG=v8:6194 Change-Id: I05fbe4ee8ac340e5c355285d0b47e4a9d52fd0a8 Reviewed-on: https://chromium-review.googlesource.com/469828 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44560}
-
- 17 Oct, 2016 1 commit
-
-
jochen authored
R=machenbach@chromium.org,titzer@chromium.org,bmeurer@chromium.org,jgruber@chromium.org BUG= CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg,v8_mac_dbg;master.tryserver.chromium.android:android_arm64_dbg_recipe Review-Url: https://codereview.chromium.org/2416243002 Cr-Commit-Position: refs/heads/master@{#40350}
-
- 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}
-
- 18 Aug, 2016 1 commit
-
-
rmcilroy authored
Removes all accesses to the Isolate during bytecode generation and the bytecode pipeline. Adds an DisallowIsolateAccessScope which is used to enforce this invariant within the BytecodeGenerator. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2242193002 Cr-Commit-Position: refs/heads/master@{#38716}
-
- 08 Jul, 2016 1 commit
-
-
yangguo authored
R=bmeurer@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2112853002 Cr-Commit-Position: refs/heads/master@{#37602}
-
- 28 Jun, 2016 2 commits
-
-
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}
-
yangguo authored
R=bmeurer@chromium.org, jgruber@chromium.org BUG=v8:5117 Review-Url: https://codereview.chromium.org/2095893002 Cr-Commit-Position: refs/heads/master@{#37309}
-
- 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
-
-
rmcilroy authored
This moves processing of jumps out of bytecode array builder and into bytecode array writer. This simplifies the pipeline by avoiding having to flush for offset and patch up offsets in bytecode array builder based on what was emitted by the bytecode array writer. This also enables future refactorings to add dead code elimination back into the pipeline, and move processing of scalable operand sizes to the end of the pipeline (in the bytecode array writer) rather than having to deal with scalable operand types throughout pipeline. BUG=v8:4280,chromium:616064 Review-Url: https://codereview.chromium.org/2035813002 Cr-Commit-Position: refs/heads/master@{#36716}
-
- 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}
-