- 14 Sep, 2016 1 commit
-
-
jgruber authored
This implements https://github.com/tc39/ecma262/pull/627/. BUG=v8:5360 Review-Url: https://codereview.chromium.org/2339443002 Cr-Commit-Position: refs/heads/master@{#39402}
-
- 13 Sep, 2016 2 commits
-
-
mstarzinger authored
This adds a regression test for a bug where {OsrPoll} instructions within the bytecode stream ended up outside of actual loops. This has been fixed already, by merging {OsrPoll} into the backwards branch. R=rmcilroy@chromium.org TEST=mjsunit/regress/regress-crbug-645888 BUG=chromium:645888 Review-Url: https://codereview.chromium.org/2337033002 Cr-Commit-Position: refs/heads/master@{#39385}
-
mvstanton authored
To make better inlining decisions, it's good to have call counts for poly/mega-morphic cases. This CL makes it work for calls, and another will follow to better unify the code between constructor calls and normal calls (and thence, to record megamorphic call counts there as well). BUG= Review-Url: https://codereview.chromium.org/2325083003 Cr-Commit-Position: refs/heads/master@{#39377}
-
- 12 Sep, 2016 2 commits
-
-
cbruni authored
The raw pointer to the parameter_map might get stale in case of accessors present on the arguments object. Drive-by-fix: use nullptr instead of the_hole with isolate access. BUG=chromium:645680 Review-Url: https://codereview.chromium.org/2332503002 Cr-Commit-Position: refs/heads/master@{#39359}
-
adamk authored
The whitelist is populated with those inline intrinsics that are lowered in JSIntrinsicInlining and were not previously blacklisted. Thus the only additional FrameStates this CL adds are those where the caller tries to call the INLINE version of an intrinsic but ends up calling the RUNTIME version instead. R=bmeurer@chromium.org BUG=chromium:644631 Review-Url: https://codereview.chromium.org/2331543002 Cr-Commit-Position: refs/heads/master@{#39357}
-
- 09 Sep, 2016 1 commit
-
-
mstarzinger authored
This fixes a corner-case where the bytecode was using the <new.target> register directly without going through the local variable. The value might be clobbered because the deoptimizer doesn't properly restore the value. The label will causes bytecode pipeline to be flushed and hence ensure {BytecodeRegisterOptimizer} doesn't reuse <new.target> anymore. R=rmcilroy@chromium.org TEST=mjsunit/regress/regress-crbug-645103 BUG=chromium:645103 Review-Url: https://codereview.chromium.org/2325133002 Cr-Commit-Position: refs/heads/master@{#39306}
-
- 08 Sep, 2016 4 commits
-
-
adamk authored
Before this change, the spread desugaring would naively call `%AppendElement($R, the_hole)` and in some cases $R would have a non-holey elements kind, putting the array into the bad state of exposing holes to author code. This patch avoids calling %AppendElement with a hole, instead simply incrementing $R.length when it sees a hole in the literal (this is safe because $R is known to be an Array). The existing logic for elements transitions takes care of giving the array a holey ElementsKind. BUG=chromium:644215 Review-Url: https://codereview.chromium.org/2321533003 Cr-Commit-Position: refs/heads/master@{#39294}
-
mstarzinger authored
This adds support to the deoptimizer to materialize ContextExtension objects that have been de-materialized by escape analysis. This is follow-up to the inline allocation of such objects during the create lowering phase (i.e. JSCreateWithContext and JSCreateCatchContext). R=bmeurer@chromium.org TEST=mjsunit/regress/regress-crbug-644245 BUG=chromium:644245 Review-Url: https://codereview.chromium.org/2317353003 Cr-Commit-Position: refs/heads/master@{#39270}
-
bmeurer authored
When lowering Array.prototype.push/.pop to the fast inlined version, we first need to ensure that all prototypes (including the Object.prototype) are stable. R=mvstanton@chromium.org BUG=chromium:644689 Review-Url: https://codereview.chromium.org/2319533005 Cr-Commit-Position: refs/heads/master@{#39266}
-
bmeurer authored
The optimization is not correct for unsigned output types, and we the overall complexity seems too high. We need to find a better way to take into account the input/output type restrictions. Also added a regression test for the unsigned output bug. BUG=v8:5267,v8:5270,v8:5357 TBR=jarin@chromium.org Review-Url: https://codereview.chromium.org/2320013002 Cr-Commit-Position: refs/heads/master@{#39262}
-
- 07 Sep, 2016 1 commit
-
-
lpy authored
Lexically declared "arguments" in sloppy mode will throw redeclaration error currently, this patch fixes it by delaying the declaration of arguments until we fully parse parameter list and function body. BUG=v8:4577 LOG=N Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa Review-Url: https://codereview.chromium.org/2290753003 Cr-Original-Commit-Position: refs/heads/master@{#39109} Cr-Commit-Position: refs/heads/master@{#39230}
-
- 06 Sep, 2016 2 commits
-
-
mstarzinger authored
This adds handling of {IrOpcode::kObjectIsReceiver} nodes to the escape status analysis. Such uses are treated as escaping for now until we add dedicated handling to the escape analysis reducer. R=bmeurer@chromium.org TEST=mjsunit/regress/regress-crbug-631027 BUG=chromium:631027 Review-Url: https://codereview.chromium.org/2317623003 Cr-Commit-Position: refs/heads/master@{#39205}
-
rmcilroy authored
The constructor and new.target arguments were passed to CallConstruct in the wrong order by BytecodeGraphBuilder, which caused subclassing to be incorrect when optimizing from bytecode. Also clean up some unecessary functions in interpreter.cc found while figuring this out. BUG=chromium:642409 Review-Url: https://codereview.chromium.org/2312103002 Cr-Commit-Position: refs/heads/master@{#39204}
-
- 05 Sep, 2016 1 commit
-
-
mstarzinger authored
This handles the case where preparation of bytecode might fail inside Compiler::EnsureBytecode due to the underlying function being a fully validated asm.js module. We simply bailout of bytecode preparation. R=bradnelson@chromium.org TEST=mjsunit/regress/regress-crbug-644111 BUG=chromium:644111 Review-Url: https://codereview.chromium.org/2309853002 Cr-Commit-Position: refs/heads/master@{#39187}
-
- 02 Sep, 2016 3 commits
-
-
jgruber authored
BUG=v8:5342 Review-Url: https://codereview.chromium.org/2307783002 Cr-Commit-Position: refs/heads/master@{#39124}
-
http://crbug.com/642056bmeurer authored
The bug itself was already fixed in ToT as part of http://crrev.com/2263273003. R=machenbach@chromium.org BUG=chromium:642056 Review-Url: https://codereview.chromium.org/2306913002 Cr-Commit-Position: refs/heads/master@{#39117}
-
machenbach authored
Revert of Allow lexically declared "arguments" in function scope in sloppy mode. (patchset #5 id:100001 of https://codereview.chromium.org/2290753003/ ) Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/9470 Original issue's description: > Allow lexically declared "arguments" in function scope in sloppy mode. > > Lexically declared "arguments" in sloppy mode will throw redeclaration error > currently, this patch fixes it by delaying the declaration of arguments until we > fully parse parameter list and function body. > > BUG=v8:4577 > LOG=N > > Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa > Cr-Commit-Position: refs/heads/master@{#39109} TBR=adamk@chromium.org,mythria@chromium.org,lpy@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4577 Review-Url: https://codereview.chromium.org/2304853002 Cr-Commit-Position: refs/heads/master@{#39115}
-
- 01 Sep, 2016 3 commits
-
-
lpy authored
Lexically declared "arguments" in sloppy mode will throw redeclaration error currently, this patch fixes it by delaying the declaration of arguments until we fully parse parameter list and function body. BUG=v8:4577 LOG=N Review-Url: https://codereview.chromium.org/2290753003 Cr-Commit-Position: refs/heads/master@{#39109}
-
bmeurer authored
R=jarin@chromium.org BUG=chromium:643073 Review-Url: https://codereview.chromium.org/2299903002 Cr-Commit-Position: refs/heads/master@{#39065}
-
bmeurer authored
We use a signaling NaN to represent the hole in FAST_HOLEY_DOUBLE_ELEMENTS backing stores, but on Intel processors, the C++ compiler may decide to (or be forced to due to calling conventions) use X87 registers for double values. However transfering to X87 registers automatically quietens the NaNs and there's no way to disable this. Therefore we should just always load the hole NaN from the canonical place identified by the address_of_hole_nan external reference instead, which might even be more efficient in some cases. R=jarin@chromium.org, jkummerow@chromium.org BUG=v8:5332 Review-Url: https://codereview.chromium.org/2303643002 Cr-Commit-Position: refs/heads/master@{#39062}
-
- 31 Aug, 2016 1 commit
-
-
bmeurer authored
When we try to further fold previously folded allocations in Crankshaft GVN we don't properly transform the allocations involved, which causes the mechanism to leave holes in the new/old space (and thereby violate the iterability property of the new/old space). BUG=chromium:621868 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2297983003 Cr-Commit-Position: refs/heads/master@{#39040}
-
- 30 Aug, 2016 1 commit
-
-
bmeurer authored
TBR=machenbach@chromium.org BUG=chromium:635798,chromium:638295 Review-Url: https://codereview.chromium.org/2288813003 Cr-Commit-Position: refs/heads/master@{#38991}
-
- 29 Aug, 2016 1 commit
-
-
littledan authored
Tail calls don't make sense from async functions and generators, as each activation of these functions needs to make a new, distnict, non-reused generator object. These tail calls are not required per spec. This patch disables both syntactic and implicit tail calls in async functions and generators. R=neis BUG=v8:5301,chromium:639270 Review-Url: https://codereview.chromium.org/2278413003 Cr-Commit-Position: refs/heads/master@{#38986}
-
- 24 Aug, 2016 2 commits
-
-
mstarzinger authored
This preserves the original shared code of the underlying function when bytecode is provided. The method in question should only ensure bytecode is present, but should avoid switching compilation tiers of the given function. It might be that the function was fast-tracked to baseline by inlining without going through the interpreted tier first. R=rmcilroy@chromium.org TEST=mjsunit/regress/regress-crbug-635923 BUG=chromium:635923 Review-Url: https://codereview.chromium.org/2278543002 Cr-Commit-Position: refs/heads/master@{#38866}
-
bmeurer authored
Don't bother using %_IsJSReceiver, which immediately gets lowered to ObjectIsReceiver anyways (by the JSIntrinsicLowering), but requires some complicated rewiring of effect/control chains. R=mstarzinger@chromium.org BUG=chromium:640369 Review-Url: https://codereview.chromium.org/2271973003 Cr-Commit-Position: refs/heads/master@{#38864}
-
- 23 Aug, 2016 1 commit
-
-
bradnelson authored
Make use of %IsAsmWasmCode in place of Wasm.instantiateModuleFromAsm, in order to reduce the surface area of the Wasm object, and to focus on testing asm.js coming in via the parser. Ignore extra CONST_LEGACY assignment introduced by the parser when modules have the form: (function Foo(a, b, c) {..}); This requires both a validator and AsmWasmBuilder change. Move stdlib use collection to import time, to reject modules that import a function, even if not used. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203 LOG=N R=jpp@chromium.org,titzer@chromium.org Review-Url: https://codereview.chromium.org/2264913002 Cr-Commit-Position: refs/heads/master@{#38806}
-
- 19 Aug, 2016 1 commit
-
-
bradnelson authored
Record which asm.js stdlib members are used and add a check that NaN is actually correctly set. Other stdlib members to be added in a later change. Also add a stdlib argument to Wasm.instantiateModuleFromAsm, in preparation for that function to be replaced by normal asm.js instantiation. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203 LOG=N R=jpp@chromium.org,titzer@chromium.org Review-Url: https://codereview.chromium.org/2251433002 Cr-Commit-Position: refs/heads/master@{#38760}
-
- 18 Aug, 2016 2 commits
-
-
mstarzinger authored
This fixes canonicalization of {SharedFunctionInfo} objects in the {Compiler::GetSharedFunctionInfo} method when bytecode is preserved. Eager compilation is only triggered when no code is present. R=rmcilroy@chromium.org TEST=mjsunit/regress/regress-crbug-638551 BUG=chromium:638551 Review-Url: https://codereview.chromium.org/2245263006 Cr-Commit-Position: refs/heads/master@{#38709}
-
rmcilroy authored
Ensures SMI values have SMI type even if they have a dot (e.g., 1.0). Adds SMI_WITH_DOT type to maintain this. BUG=chromium:638134 Review-Url: https://codereview.chromium.org/2248693005 Cr-Commit-Position: refs/heads/master@{#38698}
-
- 12 Aug, 2016 2 commits
-
-
bmeurer authored
Properly deoptimize if the left hand side of a CheckedInt32Mod is negative and the result of the operation is zero. R=jarin@chromium.org BUG=v8:5286 Review-Url: https://codereview.chromium.org/2243803002 Cr-Commit-Position: refs/heads/master@{#38615}
-
jgruber authored
This bug was triggered by a very specific combination: * A context-allocated variable at script scope. * OSR optimization. * A scheduled breakpoint, which triggers at stack checks. Stack checks differ from other possible breakpoint locations in that the context (among other things) may be in a register and not on the stack, making it impossible to recover during deoptimization. The frame_inspector then returns undefined when asked for the context. In GetFrameDetails, handle this case by omitting all context-allocated variables. BUG=v8:5279 Review-Url: https://codereview.chromium.org/2245603002 Cr-Commit-Position: refs/heads/master@{#38611}
-
- 10 Aug, 2016 1 commit
-
-
bmeurer authored
For holey/growing keyed stores, we need to check that there are no setters in the prototype chain and protect against changes to that via code dependencies. R=verwaest@chromium.org BUG=v8:5275,v8:5276 Review-Url: https://codereview.chromium.org/2231683002 Cr-Commit-Position: refs/heads/master@{#38514}
-
- 09 Aug, 2016 2 commits
-
-
bmeurer authored
When we compile a growing store in TurboFan, we don't pass a (native) context to the %GrowArrayElements fallback function, as the whole logic is actually context independent. However, that means that we need to bailout early in case the object is a prototype, which requires context dependent checks in the array protector code. R=cbruni@chromium.org BUG=chromium:635798 Review-Url: https://codereview.chromium.org/2224253003 Cr-Commit-Position: refs/heads/master@{#38491}
-
rmcilroy authored
BUG=chromium:635429 Review-Url: https://codereview.chromium.org/2228503004 Cr-Commit-Position: refs/heads/master@{#38474}
-
- 08 Aug, 2016 1 commit
-
-
hpayer authored
BUG=chromium:634900 Review-Url: https://codereview.chromium.org/2223493002 Cr-Commit-Position: refs/heads/master@{#38435}
-
- 05 Aug, 2016 4 commits
-
-
mstarzinger authored
This fixes the runtime profiler to no longer assume that seeing an optimized frame on the stack implies the underlying function is not being interpreted when entered normally. This no longer holds with code generated for OSR directly from bytecode (not installed on function). R=rmcilroy@chromium.org TEST=mjsunit/regress/regress-crbug-632800 BUG=chromium:632800 Review-Url: https://codereview.chromium.org/2208603005 Cr-Commit-Position: refs/heads/master@{#38360}
-
mstarzinger authored
This makes sure we prevent a tier-up for function which also have an optimized activation of OSR code on the stack. In case the OSR code deoptimizes, it needs the bytecode to still be around. R=rmcilroy@chromium.org TEST=mjsunit/regress/regress-5262 BUG=v8:5262 Review-Url: https://codereview.chromium.org/2206363004 Cr-Commit-Position: refs/heads/master@{#38359}
-
yangguo authored
R=mstarzinger@chromium.org BUG=chromium:633999 Review-Url: https://codereview.chromium.org/2215713002 Cr-Commit-Position: refs/heads/master@{#38358}
-
bmeurer authored
We don't need to add stability dependencies on JSObject prototypes when storing to an element, because we do the map check (and thereby guard the elements kind) and we also properly deoptimize on holes if the array protector is not usable. R=verwaest@chromium.org BUG=chromium:616709 Review-Url: https://codereview.chromium.org/2198833002 Cr-Commit-Position: refs/heads/master@{#38355}
-
- 04 Aug, 2016 1 commit
-
-
adamk authored
This was dropped accidentally in bb97d27a. R=verwaest@chromium.org BUG=chromium:633884 Review-Url: https://codereview.chromium.org/2203213003 Cr-Commit-Position: refs/heads/master@{#38345}
-