- 14 Feb, 2019 1 commit
-
-
Dan Elphick authored
If enable_omit_source_positions is true (defaults to false), source position tables are not generated when compiling bytecode. They will then be regenerated when exceptions are thrown. This adds a new function Compiler::CollectSourcePositions which given a SharedFunctionInfo with bytecode but no source position table re-parses and regenerates the bytecode but this time with source positions collection enabled. Note this will reparse all inner functions that have previously been compiled since the preparse data is no longer available. With the flag enabled there still 18 test failures mostly related to debugging. v8: 8510 Change-Id: I46dff9818d8a89c901ba8ae8df94dcaca83aa658 Reviewed-on: https://chromium-review.googlesource.com/c/1385165 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#59595}
-
- 27 Dec, 2018 1 commit
-
-
Igor Sheludko authored
Bug: v8:8477, v8:8562 Change-Id: Id97f5b53fe6e6a696d8955acc1ab1bc5ac2f4052 Reviewed-on: https://chromium-review.googlesource.com/c/1388527 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#58474}
-
- 23 Jul, 2018 1 commit
-
-
Stephan Herhut authored
api.h had an implicit dependency on objects-inl.h. Bug: v8:7490 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I56ef7abefed7205bdbff2aa5f451f1a843bef9f9 Reviewed-on: https://chromium-review.googlesource.com/1145191Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Stephan Herhut <herhut@chromium.org> Cr-Commit-Position: refs/heads/master@{#54616}
-
- 14 Apr, 2018 1 commit
-
-
Jakob Kummerow authored
The "Address" type is V8's general-purpose type for manipulating memory addresses. Per the C++ spec, pointer arithmetic and pointer comparisons are undefined behavior except within the same array; since we generally don't operate within a C++ array, our general-purpose type shouldn't be a pointer type. Bug: v8:3770 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779 Reviewed-on: https://chromium-review.googlesource.com/988657 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#52601}
-
- 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}
-
- 24 Jan, 2018 1 commit
-
-
Leszek Swirski authored
The SwitchOnGeneratorState bytecode now also falls through if the generator object is undefined (so that we don't need that jump) and restores generator context (so that we don't need that PushContext). This saves 10 bytes per generator. Change-Id: Ie0872c827119b9f1d1e9244d3be6496a30cd9620 Reviewed-on: https://chromium-review.googlesource.com/867051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50845}
-
- 23 Jan, 2018 1 commit
-
-
Leszek Swirski authored
Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
-
- 22 Jan, 2018 1 commit
-
-
Leszek Swirski authored
Instead of requiring the pattern that a SuspendGenerator must be followed by a Return, make SuspendGenerator return directly. This can, in the future, simplify some of the reasoning around generator suspends. Change-Id: I94c0156a89dc0e1c0bc306bc57acf766f3b4deb5 Reviewed-on: https://chromium-review.googlesource.com/857463Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#50748}
-
- 21 Nov, 2017 1 commit
-
-
Clemens Hammacher authored
Currently the SourcePositionTableBuilder requires a Zone because it holds a ZoneVector<byte> of the encoded entries. Since ZoneVector is a suboptimal data structure anyway, and for Liftoff we don't even have a Zone allocated currently, this CL replaces the ZoneVector by std::vector. R=mstarzinger@chromium.org Bug: v8:6600 Change-Id: I8010143e917e2351664e2b53746753b597f4407a Reviewed-on: https://chromium-review.googlesource.com/779181Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#49534}
-
- 07 Nov, 2017 1 commit
-
-
Mircea Trofin authored
This is in preparation for wasm on the native heap. All the aforementioned API needs is the address where the JIT-ed code starts. This refactoring reduces the dependency of the API to just that. Bug: v8:6876 Change-Id: I00bbb171398f581db41b8a74ab719e8ea4db52c4 Reviewed-on: https://chromium-review.googlesource.com/755624Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49204}
-
- 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}
-
- 08 Sep, 2017 1 commit
-
-
Jaroslav Sevcik authored
The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
-
- 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}
-
- 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}
-
- 22 May, 2017 1 commit
-
-
Wiktor Garbacz authored
Change-Id: I20ed35a7fb5104a9cc66bb54fa8966589c43d7f9 Reviewed-on: https://chromium-review.googlesource.com/507287Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Jochen Eisinger <jochen@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#45458}
-
- 16 May, 2017 1 commit
-
-
Leszek Swirski authored
Bug: v8:6351 Bug: v8:6366 Change-Id: I3ec9bd75031b2c6148278353461f442c1eaf60ca Reviewed-on: https://chromium-review.googlesource.com/506015 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45335}
-
- 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}
-
- 03 Apr, 2017 1 commit
-
-
rmcilroy authored
Translates code of the form 'if (x === undefined)' into the JumpIfUndefined bytecode, and similarly for comparisons with null. Also adds bytecodes for JumpIfNotUndefined / Null. Moves the peephole optimization for CompareUndefined out of the peephole optimizer and into the BytecodeGenerator, having the side-effect of enabling it for comparisons with undefined on both side of the compare operation. BUG=v8:6107 Review-Url: https://codereview.chromium.org/2793923002 Cr-Commit-Position: refs/heads/master@{#44341}
-
- 24 Jan, 2017 1 commit
-
-
leszeks authored
Since JumpLoop is always backwards, and other jumps are always forwards, we can store the jump offset as an always positive integer and decide on the jump direction based on the bytecode. This will save a small amount of space for large-ish for loops (>128 bytecodes). Review-Url: https://codereview.chromium.org/2641443002 Cr-Commit-Position: refs/heads/master@{#42638}
-
- 09 Jan, 2017 1 commit
-
-
marja authored
Downside: this adds all kinds of weird includes in the .cc files. (See design doc linked in the bug.) BUG=v8:5402 Review-Url: https://codereview.chromium.org/2622503002 Cr-Commit-Position: refs/heads/master@{#42140}
-
- 15 Dec, 2016 1 commit
-
-
rmcilroy authored
Templatizes the AccumulatorUsage and OperandType for BytecodeNode creation and BytecodeRegisterOptimizer::PrepareForBytecode. This allows the compiler to statically know whether the bytecode being created accesses the accumulator and what operand types need scaling, avoiding runtime checks in the code. Also removes BytecodeNode::set_bytecode methods. Review-Url: https://codereview.chromium.org/2542903003 Cr-Commit-Position: refs/heads/master@{#41706}
-
- 07 Dec, 2016 1 commit
-
-
caitp authored
Introduces: - a new AST node representing the GetIterator() algorithm in the specification, to be used by ForOfStatement, YieldExpression (in the case of delegating yield*), and the future `for-await-of` loop proposed in http://tc39.github.io/proposal-async-iteration/#sec-async-iterator-value-unwrap-functions. - a new opcode (JumpIfJSReceiver), which is useful for `if Type(object) is not Object` checks which are common throughout the specification. This node is easily eliminated by TurboFan. The AST node is desugared specially in bytecode, rather than manually when building the AST. The benefit of this is that desugaring in the BytecodeGenerator is much simpler and easier to understand than desugaring the AST. This also reduces parse time very slightly, and allows us to use LoadIC rather than KeyedLoadIC, which seems to have better baseline performance. This results in a ~20% improvement in test/js-perf-test/Iterators micro-benchmarks, which I believe owes to the use of the slightly faster LoadIC as opposed to the KeyedLoadIC in the baseline case. Both produce identical optimized code via TurboFan when the type check can be eliminated, and the load can be replaced with a constant value. BUG=v8:4280 R=bmeurer@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, neis@chromium.org, jarin@chromium.org TBR=rossberg@chromium.org Review-Url: https://codereview.chromium.org/2557593004 Cr-Commit-Position: refs/heads/master@{#41555}
-
- 14 Nov, 2016 1 commit
-
-
tebbi authored
This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset. SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id: - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray - The SourcePosition of the inlining. Recursively, this yields the full inlining stack. Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions(). If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function. So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer. All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file. At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts. I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases. The following additional changes were necessary: - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id. - The class HPositionInfo was effectively dead code and is now removed. - SourcePosition has new printing and information facilities, including computing a full inlining stack. - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file. - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions(). - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids. - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already). BUG=v8:5432 Review-Url: https://codereview.chromium.org/2451853002 Cr-Commit-Position: refs/heads/master@{#40975}
-
- 11 Nov, 2016 1 commit
-
-
ulan authored
BUG=v8:5614 Review-Url: https://codereview.chromium.org/2493183002 Cr-Commit-Position: refs/heads/master@{#40918}
-
- 07 Oct, 2016 1 commit
-
-
rmcilroy authored
A wide jump can be patched with a non-wide jump target operand, so the DCHECK added in r39637 was wrong. BUG=chromium:652430 Review-Url: https://codereview.chromium.org/2400203002 Cr-Commit-Position: refs/heads/master@{#40090}
-
- 22 Sep, 2016 3 commits
-
-
jyan authored
R=rmcilroy@chromium.org, mythria@chromium.org, leszeks@chromium.org BUG= Review-Url: https://codereview.chromium.org/2362453003 Cr-Commit-Position: refs/heads/master@{#39644}
-
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}
-
- 13 Sep, 2016 1 commit
-
-
mstarzinger authored
This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
-
- 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}
-
- 17 Aug, 2016 1 commit
-
-
rmcilroy authored
Now that all backends use the source position builder to record source positions, simplify the code line logging events to take a source position table on code creation. This means that the source position table builder no longer needs to access the isolate until the table is generated. This is required for off-thread bytecode generation. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2248673002 Cr-Commit-Position: refs/heads/master@{#38676}
-
- 10 Aug, 2016 2 commits
-
-
rmcilroy authored
Don't allocate handles in the bytecode array writer, to allow off-thread bytecode generation. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2226333002 Cr-Commit-Position: refs/heads/master@{#38550}
-
rmcilroy authored
Updates a number of AST operations to avoid dereferencing handles such that they can safely be called off-thread. Also adds a HandleDereferenceMode argument to some operations where handles are compared. If handle dereferencing is allowed, the handles are compared directly, if not then their locations are compared (which relies on the handles being created in a CanonicalHandleScope). BUG=v8:5203 TBR=adamk@chromium.org Review-Url: https://codereview.chromium.org/2223523002 Cr-Commit-Position: refs/heads/master@{#38526}
-
- 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}
-