- 22 Nov, 2016 12 commits
-
-
clemensh authored
When disassembling functions for the inspector, we used an internal text representation before. This CL implements the official text format like it is understood by the spec interpreter. Example output: func $main (param i32) (result i32) block i32 get_local 0 i32.const 2 i32.lt_u if i32.const -2 return end get_local 0 call_indirect 0 end R=rossberg@chromium.org, titzer@chromium.org BUG=chromium:659715 Review-Url: https://codereview.chromium.org/2520943002 Cr-Commit-Position: refs/heads/master@{#41172}
-
mstarzinger authored
R=neis@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2523693002 Cr-Commit-Position: refs/heads/master@{#41171}
-
mstarzinger authored
This fixes stack unwinding to always recompute the stack pointer for interpreted frames. For frames materialized by the deoptimizer we elide the handler frame in between, hence arguments being pushed on the stack will no longer be pushed into the handler frame but into the interpreted frame directly. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-662830 BUG=chromium:662830 Review-Url: https://codereview.chromium.org/2517203003 Cr-Commit-Position: refs/heads/master@{#41170}
-
bmeurer authored
BUG=chromium:667689 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2518313002 Cr-Commit-Position: refs/heads/master@{#41169}
-
tebbi authored
The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results. Other changes in this CL: - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front. - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan. - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention. - I removed CodeDeoptEvent::position, as it is no longer used. R=alph@chromium.org BUG=v8:5432 Review-Url: https://codereview.chromium.org/2503393002 Cr-Commit-Position: refs/heads/master@{#41168}
-
cbruni authored
R=hablich@chromium.org NOTRY=true NOTREECHECKS=true Review-Url: https://codereview.chromium.org/2514283003 Cr-Commit-Position: refs/heads/master@{#41167}
-
bmeurer authored
TurboFan can indeed comsume NumberOrOddball feedback for abstract relational comparisons, so we should just provide it from Ignition. Drive-by-fix: Add a DCHECK to protect against abstract/strict equality number comparison accidentially utilizing Oddball feedback. BUG=v8:5267,v8:5400 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2518283002 Cr-Commit-Position: refs/heads/master@{#41166}
-
jbroman authored
This code should not access bytes out of the permitted range in order to check the range of a possible UTF-8 value. Instead, the length check should occur before such checks. BUG=chromium:667260, chromium:662822 Review-Url: https://codereview.chromium.org/2520053003 Cr-Commit-Position: refs/heads/master@{#41165}
-
yangguo authored
R=jshin@chromium.org Review-Url: https://codereview.chromium.org/2514333002 Cr-Commit-Position: refs/heads/master@{#41164}
-
bmeurer authored
Make use of the previously introduced String feedback for compare operations in TurboFan. R=jarin@chromium.org BUG=v8:5267,v8:5400 Review-Url: https://codereview.chromium.org/2523463002 Cr-Commit-Position: refs/heads/master@{#41163}
-
kozyatinskiy authored
BUG=none R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2505823002 Cr-Commit-Position: refs/heads/master@{#41162}
-
pfeldman authored
BUG=chromium:651324 Review-Url: https://codereview.chromium.org/2522593005 Cr-Commit-Position: refs/heads/master@{#41161}
-
- 21 Nov, 2016 28 commits
-
-
gdeepti authored
- Simd Scalar lowering should be conditionally disabled if the architecture has a native SIMD implementation. - Enable scalar lowering tests on all architectures instead of only x64. R=bbudge@chromium.org, aseemgarg@chromium.org Review-Url: https://codereview.chromium.org/2514663002 Cr-Commit-Position: refs/heads/master@{#41160}
-
mtrofin authored
The verifier needs to use the block and assessments in that block corresponding to a predecessor of a "pending" assessment. Not doing that causes incorrect assessments when 2 locations are swapped. BUG=665402 Review-Url: https://codereview.chromium.org/2515803002 Cr-Commit-Position: refs/heads/master@{#41159}
-
eholk authored
This fixes a bug found by the fuzzer where we would attempt to dereference a null handle if memory allocation failed. In this case, the failure was because the amount of memory requested was above V8's hardcoded limit. BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=666741 Review-Url: https://codereview.chromium.org/2514983002 Cr-Commit-Position: refs/heads/master@{#41158}
-
fedor authored
Export JS_API_OBJECT_TYPE, JS_SPECIAL_API_OBJECT_TYPE. Exports JSObject::kHeaderSize to ease the inspection of internal fields in llnode. BUG= R=machenbach Review-Url: https://codereview.chromium.org/2514063002 Cr-Commit-Position: refs/heads/master@{#41157}
-
thestig authored
Instead of directly using v8_enable_inspector_override from build_overrides/v8.gni in all the GN configs, set a v8_enable_inspector variable based on v8_enable_inspector_override and use that everywhere. This is the more common pattern seen in over projects, and reduces the need to include //build_overrides/v8.gni in many files. Review-Url: https://codereview.chromium.org/2520683002 Cr-Commit-Position: refs/heads/master@{#41156}
-
ahaas authored
R=titzer@chromium.org CC=mtrofin@chromium.org Review-Url: https://codereview.chromium.org/2520853003 Cr-Commit-Position: refs/heads/master@{#41155}
-
titzer authored
R=mstarzinger@chromium.org,clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2520963002 Cr-Commit-Position: refs/heads/master@{#41154}
-
leszeks authored
This pre-calculates and stores a vector of bytecode offsets, and then allows one to iterate over it backwards. This could probably be adapted to a bidirectional/random access iterator if we wanted to, but for now reverse is all we need. Review-Url: https://codereview.chromium.org/2518003002 Cr-Commit-Position: refs/heads/master@{#41153}
-
leszeks authored
Refactors the bytecode array iterator to separate the iteration and the bytecode parameter access, placing the latter into a separate super-class. This will allow us to have other forms of access, e.g. reverse iteration. Review-Url: https://codereview.chromium.org/2519923002 Cr-Commit-Position: refs/heads/master@{#41152}
-
tebbi authored
BUG=v8:5296 Review-Url: https://codereview.chromium.org/2320753002 Cr-Commit-Position: refs/heads/master@{#41151}
-
cbruni authored
Revert of [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters. (patchset #10 id:180001 of https://codereview.chromium.org/2511093002/ ) Reason for revert: Wronged it even more. Original issue's description: > [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters > > RuntimeTimerScopes always subtract their own time from the parent timer's > counter to properly account for the own time. Once a scope is destructed it > adds it own timer to the current active counter. However, if the current > counter is changed with CorrectCurrentCounterId we will attribute all the > subtimers to the previous counter, and add the own time to the new counter. > This way it is possible to end up with negative times in certain counters but > the overall would still be correct. > > BUG= > > Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8 > Cr-Commit-Position: refs/heads/master@{#41142} TBR=ishell@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/2519073002 Cr-Commit-Position: refs/heads/master@{#41150}
-
yangguo authored
R=jgruber@chromium.org BUG=v8:5530 Review-Url: https://codereview.chromium.org/2516343003 Cr-Commit-Position: refs/heads/master@{#41149}
-
gsathya authored
This is unused. BUG=v8:5343 TBR=littledan@chromium.org Review-Url: https://codereview.chromium.org/2513413002 Cr-Commit-Position: refs/heads/master@{#41148}
-
verwaest authored
[parser] Keep track of whether we are in a temp-zone in the parser, and don't lazy parse anymore once we are This avoids entering a nested temp zone, and fixes up tracing and runtime callstats names. BUG= Review-Url: https://codereview.chromium.org/2514353002 Cr-Commit-Position: refs/heads/master@{#41147}
-
yangguo authored
This test tests a code path that's being deprecated. There is no point in migrating it to the new debugger API. R=jgruber@chromium.org BUG=v8:5530 Review-Url: https://codereview.chromium.org/2519033002 Cr-Commit-Position: refs/heads/master@{#41146}
-
marja authored
BUG= Review-Url: https://codereview.chromium.org/2517993002 Cr-Commit-Position: refs/heads/master@{#41145}
-
mstarzinger authored
By now the compilation pipeline is flexible enough to run module tests against all variants, we should no longer choose unsupported compilers for modules. It also fixes the predicate checking for functions being "resumable" in the {AstNumberingVisitor} heuristic. R=neis@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2517143002 Cr-Commit-Position: refs/heads/master@{#41144}
-
ivica.bogosavljevic authored
Add/Shl to Lsa optimization doesn't yield any performance increase in case one of the operand is immediate, because Lsa cannot use the immediate so we use an extra instruction to load the immediate to register. On MIPSR2 and less this optimization leads to performance degradation, since Lsa is not supported on these architectures and it is emulated using Add/Shl which do support immediate as operand for Add. BUG= Review-Url: https://codereview.chromium.org/2509203003 Cr-Commit-Position: refs/heads/master@{#41143}
-
cbruni authored
RuntimeTimerScopes always subtract their own time from the parent timer's counter to properly account for the own time. Once a scope is destructed it adds it own timer to the current active counter. However, if the current counter is changed with CorrectCurrentCounterId we will attribute all the subtimers to the previous counter, and add the own time to the new counter. This way it is possible to end up with negative times in certain counters but the overall would still be correct. BUG= Review-Url: https://codereview.chromium.org/2511093002 Cr-Commit-Position: refs/heads/master@{#41142}
-
hablich authored
Revert of [turbofan] Introduce LoadFunctionPrototype simplified operator. (patchset #1 id:1 of https://codereview.chromium.org/2517913002/ ) Reason for revert: Blocks roll https://codereview.chromium.org/2517963002/ Original issue's description: > [turbofan] Introduce LoadFunctionPrototype simplified operator. > > Add a LoadFunctionPrototype simplified operator, similar to what > Crankshaft has, that loads the prototype property of a constructor > function. > > R=jarin@chromium.org > BUG=v8:5267 > > Committed: https://crrev.com/1737b2c74b50168e96ef1263def0eb43505fa80c > Cr-Commit-Position: refs/heads/master@{#41127} TBR=jarin@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5267 Review-Url: https://codereview.chromium.org/2514363002 Cr-Commit-Position: refs/heads/master@{#41141}
-
mstarzinger authored
This renames the {operand_stack} field to {register_file}, to refelct how said field is used on all {JSGeneratorObject} instances by now. This is a pure refactoring CL, not changes in semantics. R=neis@chromium.org Review-Url: https://codereview.chromium.org/2520913002 Cr-Commit-Position: refs/heads/master@{#41140}
-
yangguo authored
R=jgruber@chromium.org BUG=v8:5654 Review-Url: https://codereview.chromium.org/2511733002 Cr-Commit-Position: refs/heads/master@{#41139}
-
verwaest authored
BUG=chromium:655129 Review-Url: https://codereview.chromium.org/2520903002 Cr-Commit-Position: refs/heads/master@{#41138}
-
mstarzinger authored
This removes some outdated code that allocates a {JSGeneratorObject} for baseline code. We no longer support such a representation of generators and can rely on bytecode being available for all generators. R=neis@chromium.org Review-Url: https://codereview.chromium.org/2515253003 Cr-Commit-Position: refs/heads/master@{#41137}
-
ishell authored
BUG=chromium:666742, v8:5561 Review-Url: https://codereview.chromium.org/2512183002 Cr-Commit-Position: refs/heads/master@{#41136}
-
mstarzinger authored
This removes the deprecated generator support for resumable functions from {FullCodeGenerator}. The existing {AstNumbering} heuristic already triggers Ignition for most resumable functions, with this change we make said heuristic a hard choice and remove the deprecated code. This also has the advantage that any suspended {JSGeneratorObject} instance on the heap is guaranteed to have code based on a bytecode array. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2504223002 Cr-Commit-Position: refs/heads/master@{#41135}
-
rmcilroy authored
Revert of [Interpreter] Collect NumberOrOddball feedback in CompareOps. (patchset #2 id:20001 of https://codereview.chromium.org/2506283003/ ) Reason for revert: Turbofan doesn't do proper ToNumber conversions on NumberOrOddball equality conversions. BUG=v8:5660 Original issue's description: > [Interpreter] Collect NumberOrOddball feedback in CompareOps. > > Collect feedback for oddballs in the interpreter compare operations handlers. > This is important to ensure that we don't consider oddball comparisons as > generic, which prevents optimization. > > BUG=chromium:660947 > > Committed: https://crrev.com/721e74d9d942fd4f2e3392ea9626d9d404dbbbd0 > Cr-Commit-Position: refs/heads/master@{#41081} TBR=bmeurer@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=chromium:660947 Review-Url: https://codereview.chromium.org/2517133002 Cr-Commit-Position: refs/heads/master@{#41134}
-
ishell authored
BUG=chromium:664974, chromium:664802, v8:5561 Review-Url: https://codereview.chromium.org/2513893003 Cr-Commit-Position: refs/heads/master@{#41133}
-