- 27 Jan, 2017 1 commit
-
-
marja authored
These headers only need forward declarations. BUG=v8:5294 Review-Url: https://codereview.chromium.org/2654253002 Cr-Commit-Position: refs/heads/master@{#42740}
-
- 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}
-
- 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}
-
- 14 Oct, 2016 1 commit
-
-
jochen authored
R=machenbach@chromium.org,jgruber@chromium.org,mythria@chromium.org 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/2410353005 Cr-Commit-Position: refs/heads/master@{#40300}
-
- 20 Sep, 2016 1 commit
-
-
heimbuef authored
This is some initial cleanup to keep /src clean. The AccountingAllocator is actually exclusively used by zones and this common subfolder makes that more clear. BUG=v8:5409 Review-Url: https://codereview.chromium.org/2344143003 Cr-Commit-Position: refs/heads/master@{#39558}
-
- 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}
-
- 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}
-
- 30 Jun, 2016 1 commit
-
-
yangguo authored
R=jgruber@chromium.org BUG=v8:5117 Review-Url: https://codereview.chromium.org/2111793002 Cr-Commit-Position: refs/heads/master@{#37435}
-
- 28 Jun, 2016 1 commit
-
-
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}
-
- 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}
-
- 05 Apr, 2016 1 commit
-
-
yangguo authored
If a statement or expression does not produce any bytecode, it's position should always be overwritten by a following statement position. R=mstarzinger@chromium.org, vogelheim@chromium.org BUG=v8:4680 LOG=N Review URL: https://codereview.chromium.org/1854113002 Cr-Commit-Position: refs/heads/master@{#35252}
-
- 15 Mar, 2016 1 commit
-
-
yangguo authored
We may not emit bytecode for the evaluation of the to-be-returned expression. In that case we cannot set two return positions for a return statement (one before and one after the expression evaluation). This sets the interpreter apart from full-codegen. Make sure that we always have the second of the two return positions. Note that we end up with separate test cases for ignition and FCG. R=rmcilroy@chromium.org, vogelheim@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1801473003 Cr-Commit-Position: refs/heads/master@{#34771}
-
- 02 Mar, 2016 1 commit
-
-
rmcilroy authored
Add support to log source position offsets to the profiler. As part of this change PositionsRecorder is split into two, with the subset needed by log.cc moved into log.h and the remainder kept in assembler.h as AssemblerPositionsRecorder. The interpreter's source position table builder is updated to log positions when the profiler is active. BUG=v8:4766 LOG=N Review URL: https://codereview.chromium.org/1737043002 Cr-Commit-Position: refs/heads/master@{#34416}
-
- 24 Feb, 2016 3 commits
-
-
vogelheim authored
This reduces the memory consumption of SourcePositionTable by ca. 2/3. Over Octane, this reduces the source position table memory consumption from ~370kB to ~115kB, which makes it ca. 10% of the total bytecode size (~1.1MB) ---------------- Reland CL in order to relive the glory days, and also fix memory leak w/ ENABLE_SLOW_CHECKS. SourcePositionTableBuilder used to have a no destructor since everything was zone allocated. But if ENABLE_SLOW_CHECKS, it has a heap allocated member and thus needs a proper constructor. ASAN thankfully notices this, and V8 no longer builds since this is called during mksnapshot. Breakge example: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN%20arm64%20-%20debug%20builder/builds/4829 R=jochen@chromium.org, yangguo@chromium.org, rmcilroy@chromium.org BUG=v8:4690 LOG=y Committed: https://crrev.com/a6f41f7b8226555c5900440f6e3092b3545ee0f6 Cr-Commit-Position: refs/heads/master@{#34250} patch from issue 1704943002 at patchset 200001 (http://crrev.com/1704943002#ps200001) Review URL: https://codereview.chromium.org/1731883003 Cr-Commit-Position: refs/heads/master@{#34256}
-
vogelheim authored
Revert of Encode interpreter::SourcePositionTable as variable-length ints. (patchset #10 id:200001 of https://codereview.chromium.org/1704943002/ ) Reason for revert: Build failure on Linux64 arm64 ASAN: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN%20arm64%20-%20debug%20builder/builds/4829 (Leaks memory, somehow.) Original issue's description: > Encode interpreter::SourcePositionTable as variable-length ints. > > This reduces the memory consumption of SourcePositionTable by ca. 2/3. > Over Octane, this reduces the source position table memory consumption > from ~370kB to ~115kB, which makes it ca. 10% of the total bytecode size > (~1.1MB) > > BUG= > > Committed: https://crrev.com/a6f41f7b8226555c5900440f6e3092b3545ee0f6 > Cr-Commit-Position: refs/heads/master@{#34250} TBR=jochen@chromium.org,rmcilroy@chromium.org,yangguo@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/1728193003 Cr-Commit-Position: refs/heads/master@{#34251}
-
vogelheim authored
This reduces the memory consumption of SourcePositionTable by ca. 2/3. Over Octane, this reduces the source position table memory consumption from ~370kB to ~115kB, which makes it ca. 10% of the total bytecode size (~1.1MB) BUG= Review URL: https://codereview.chromium.org/1704943002 Cr-Commit-Position: refs/heads/master@{#34250}
-
- 11 Feb, 2016 1 commit
-
-
yangguo authored
R=rmcilroy@chromium.org, vogelheim@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1682853004 Cr-Commit-Position: refs/heads/master@{#33904}
-
- 10 Feb, 2016 1 commit
-
-
yangguo authored
The break location heavily relies on relocation info. This change abstracts that away. Currently there is only one implementation for this interface, for JIT code. Future changes will introduce an implementation to iterate bytecode arrays. R=rmcilroy@chromium.org, vogelheim@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1682853003 Cr-Commit-Position: refs/heads/master@{#33869}
-
- 05 Feb, 2016 1 commit
-
-
yangguo authored
R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1668863002 Cr-Commit-Position: refs/heads/master@{#33775}
-
- 04 Feb, 2016 1 commit
-
-
yangguo authored
This change adds the basic infrastructure to record source positions for bytecode. R=rmcilroy@chromium.org, vogelheim@chromium.org BUG=v8:4960 LOG=N Review URL: https://codereview.chromium.org/1662983002 Cr-Commit-Position: refs/heads/master@{#33726}
-