- 26 Feb, 2016 1 commit
-
-
adamk authored
Revert of [compiler] Drop the CompareNilIC. (patchset #4 id:60001 of https://codereview.chromium.org/1722193002/ ) Reason for revert: Speculative revert in attempt to fix #2 crasher on canary. Original issue's description: > [compiler] Drop the CompareNilIC. > > Since both null and undefined are also marked as undetectable now, we > can just test that bit instead of having the CompareNilIC try to collect > feedback to speed up the general case (without the undetectable bit > being used). > > Drive-by-fix: Update the type system to match the new handling of > undetectable in the runtime. > > R=danno@chromium.org > > Committed: https://crrev.com/666aec0348c8793e61c8633dee7ad29a514239ba > Cr-Commit-Position: refs/heads/master@{#34237} TBR=danno@chromium.org,verwaest@chromium.org,bmeurer@chromium.org LOG=y BUG=chromium:589897 NOTRY=true Review URL: https://codereview.chromium.org/1743433002 Cr-Commit-Position: refs/heads/master@{#34308}
-
- 25 Feb, 2016 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org BUG=v8:3956 LOG=n Review URL: https://codereview.chromium.org/1736963002 Cr-Commit-Position: refs/heads/master@{#34286}
-
- 24 Feb, 2016 4 commits
-
-
mstarzinger authored
This makes the aforementioned emitting function independent of the target architecture by leveraging existing abstractions. R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1730243002 Cr-Commit-Position: refs/heads/master@{#34263}
-
mstarzinger authored
This makes the FullCodeGenerator::EmitNamedPropertyLoad be architecture independent by adding MacroAssembler::Move helpers. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1734643002 Cr-Commit-Position: refs/heads/master@{#34259}
-
mstarzinger authored
This implements proper handling of local control flow (i.e. break and continue) that spans the boundary of a do-expression. We can no longer determine the number of operands to be dropped from the nesting of statements alone, instead we use the new precise operand stack depth tracking. R=jarin@chromium.org TEST=mjsunit/harmony/do-expressions-control BUG=v8:4488 LOG=n Review URL: https://codereview.chromium.org/1724753002 Cr-Commit-Position: refs/heads/master@{#34246}
-
bmeurer authored
Since both null and undefined are also marked as undetectable now, we can just test that bit instead of having the CompareNilIC try to collect feedback to speed up the general case (without the undetectable bit being used). Drive-by-fix: Update the type system to match the new handling of undetectable in the runtime. R=danno@chromium.org Review URL: https://codereview.chromium.org/1722193002 Cr-Commit-Position: refs/heads/master@{#34237}
-
- 23 Feb, 2016 1 commit
-
-
mstarzinger authored
This implements a mechanism to track the exact depth of the operand stack in full-codegen for every sub-expression visitation. So far we only tracked the depth at statement level, but not at expression level. With the introduction of do-expressions it will be possible to construct local control flow (i.e. break, continue and friends) that target labels at an arbitrary operand stack depth, making this tracking a prerequisite for full do-expression support. R=rossberg@chromium.org,jarin@chromium.org BUG=v8:4755,v8:4488 LOG=n Review URL: https://codereview.chromium.org/1706283002 Cr-Commit-Position: refs/heads/master@{#34211}
-
- 22 Feb, 2016 1 commit
-
-
mstarzinger authored
This removes a restriction from full-codegen that limited the usability of the --debug-code flag to only no-snap configurations. The reasoning for the restriction would still hold, if we ever put full-codegen code into the snapshot, which we don't. Also there already are several places in full-codegen that queried the FLAG_debug_code directly, a more reliable mechanism will be needed if we snapshot full code. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1722593002 Cr-Commit-Position: refs/heads/master@{#34189}
-
- 19 Feb, 2016 2 commits
-
-
bmeurer authored
This intrinsic was only supported in fullcodegen, and is actually no longer relevant for SunSpider peak performance it seems, so let's get rid of it and maybe just implement Array.prototype.join with a fast path at some point instead. R=mstarzinger@chromium.org Committed: https://crrev.com/ccf12b4bede3f1ce3ce14fb33bcc4041525a40af Cr-Commit-Position: refs/heads/master@{#34084} Review URL: https://codereview.chromium.org/1708523002 Cr-Commit-Position: refs/heads/master@{#34146}
-
ishell authored
This CL also enhances a "tail-call-megatest" which now tests product of the following cases: 1) tail caller is inlined/not-inlined 2) tail callee is inlined/not-inlined 3) tail caller has an arguments adaptor frame above or not 4) tail callee has an arguments adaptor frame above or not 5) tail callee is a sloppy/strict/possibly eval/bound/proxy function 6) tail calling via normal call/function.apply/function.call BUG=v8:4698 LOG=N Review URL: https://codereview.chromium.org/1711863002 Cr-Commit-Position: refs/heads/master@{#34143}
-
- 17 Feb, 2016 5 commits
-
-
machenbach authored
Revert of [fullcodegen] Remove the hacky %_FastOneByteArrayJoin intrinsic. (patchset #1 id:1 of https://codereview.chromium.org/1708523002/ ) Reason for revert: [Sheriff] Speculative revert for adding arm flakes: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm%20-%20sim/builds/5756 https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm%20-%20sim%20-%20novfp3/builds/3375/ And some more... Original issue's description: > [fullcodegen] Remove the hacky %_FastOneByteArrayJoin intrinsic. > > This intrinsic was only supported in fullcodegen, and is actually no > longer relevant for SunSpider peak performance it seems, so let's get > rid of it and maybe just implement Array.prototype.join with a fast > path at some point instead. > > R=mstarzinger@chromium.org > > Committed: https://crrev.com/ccf12b4bede3f1ce3ce14fb33bcc4041525a40af > Cr-Commit-Position: refs/heads/master@{#34084} TBR=mstarzinger@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1709693002 Cr-Commit-Position: refs/heads/master@{#34091}
-
bmeurer authored
This intrinsic was only supported in fullcodegen, and is actually no longer relevant for SunSpider peak performance it seems, so let's get rid of it and maybe just implement Array.prototype.join with a fast path at some point instead. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1708523002 Cr-Commit-Position: refs/heads/master@{#34084}
-
bmeurer authored
There's no need to have inline platform code for this intrinsic, which is only used when generating a descriptive string for an error, the runtime call is just fine here. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1706743002 Cr-Commit-Position: refs/heads/master@{#34080}
-
mstarzinger authored
R=rossberg@chromium.org,bmeurer@chromium.org,verwaest@chromium.org BUG=v8:3956 LOG=n Review URL: https://codereview.chromium.org/1700993002 Cr-Commit-Position: refs/heads/master@{#34067}
-
bmeurer authored
It's fine to only have the runtime call here, as it's only used in the debug mirror. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1699133002 Cr-Commit-Position: refs/heads/master@{#34056}
-
- 16 Feb, 2016 2 commits
-
-
bmeurer authored
Drive-by-fix: Remove the (now) unused %_SetValueOf and %_JSValueGetValue intrinsics from the various compilers and the runtime. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1698343002 Cr-Commit-Position: refs/heads/master@{#34037}
-
mstarzinger authored
R=bmeurer@chromium.org BUG=v8:3956 LOG=n Review URL: https://codereview.chromium.org/1693833002 Cr-Commit-Position: refs/heads/master@{#34036}
-
- 15 Feb, 2016 3 commits
-
-
bmeurer authored
Turn the fast case of ArgumentsAccessStub into a new stub FastNewSloppyArgumentsStub, which is similar to the existing FastNewStrictArgumentsStub, although not polished yet, and the slow case always went to the runtime anyway, so we can just directly emit a runtime call there. R=mstarzinger@chromium.org Committed: https://crrev.com/55b0b4f6d572531eec00ab6ebd8f6feb7c584e04 Cr-Commit-Position: refs/heads/master@{#33973} Review URL: https://codereview.chromium.org/1695633003 Cr-Commit-Position: refs/heads/master@{#33986}
-
machenbach authored
Revert of [runtime] Turn ArgumentAccessStub into FastNewSloppyArgumentsStub. (patchset #2 id:20001 of https://codereview.chromium.org/1695633003/ ) Reason for revert: [Sheriff] Breaks ASAN with mipsel compile: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20ASAN%20mipsel%20-%20debug%20builder/builds/4558/ Original issue's description: > [runtime] Turn ArgumentAccessStub into FastNewSloppyArgumentsStub. > > Turn the fast case of ArgumentsAccessStub into a new stub > FastNewSloppyArgumentsStub, which is similar to the existing > FastNewStrictArgumentsStub, although not polished yet, and the slow > case always went to the runtime anyway, so we can just directly emit > a runtime call there. > > R=mstarzinger@chromium.org > > Committed: https://crrev.com/55b0b4f6d572531eec00ab6ebd8f6feb7c584e04 > Cr-Commit-Position: refs/heads/master@{#33973} TBR=mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1701653002 Cr-Commit-Position: refs/heads/master@{#33976}
-
bmeurer authored
Turn the fast case of ArgumentsAccessStub into a new stub FastNewSloppyArgumentsStub, which is similar to the existing FastNewStrictArgumentsStub, although not polished yet, and the slow case always went to the runtime anyway, so we can just directly emit a runtime call there. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1695633003 Cr-Commit-Position: refs/heads/master@{#33973}
-
- 12 Feb, 2016 3 commits
-
-
bmeurer authored
There are only two uses of %_ObjectEquals left, which should actually use strict equality instead, so there's no need to keep this special logic at all. R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1692193002 Cr-Commit-Position: refs/heads/master@{#33948}
-
bmeurer authored
This removes support for the %Arguments and %ArgumentsLength runtime entries and their intrinsic counterparts. If you need variable arguments in any builtin, either use (strict) arguments object or rest parameters, which are both compositional across inlining (in TurboFan), and not that much slower compared to the %_Arguments hackery. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1688163004 Cr-Commit-Position: refs/heads/master@{#33943}
-
bmeurer authored
The FastNewStrictArgumentsStub is very similar to the recently added FastNewRestParameterStub, it's actually almost a copy of it, except that it doesn't have the fast case we have for the empty rest parameter. This patch improves strict arguments in TurboFan and fullcodegen by up to 10x compared to the previous version. Also introduce proper JSSloppyArgumentsObject and JSStrictArgumentsObject for the in-object properties instead of having them as constants in the Heap class. Drive-by-fix: Use this stub and the FastNewRestParameterStub in the interpreter to avoid the runtime call overhead for strict arguments and rest parameter creation. R=jarin@chromium.org TBR=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1693513002 Cr-Commit-Position: refs/heads/master@{#33925}
-
- 11 Feb, 2016 2 commits
-
-
ishell authored
1) Update profiling counters in Full codegen. 2) Call Runtime::kTraceTailCall when tracing is on test/mjsunit/es6/tail-call-simple.js is disabled for now, because Turbofan does not fully support TCO yet. BUG=v8:4698 LOG=N Review URL: https://codereview.chromium.org/1670133002 Cr-Commit-Position: refs/heads/master@{#33886}
-
bmeurer authored
Add dedicated %LoadLookupSlot, %LoadLookupSlotInsideTypeof, %LoadLookupSlotForCall, %StoreLookupSlot_Sloppy and %StoreLookupSlot_Strict runtime entry points and use them appropriately in the various compilers. This way we can finally drop the machine operators from the JS graph level completely in TurboFan. Also drop the funky JSLoadDynamic operator from TurboFan, which was by now just a small wrapper around the runtime call to %LoadLookupSlot. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1683103002 Cr-Commit-Position: refs/heads/master@{#33880}
-
- 10 Feb, 2016 1 commit
-
-
verwaest authored
Mark null and undefined as undetectable, and use it to handle abstract equality comparison in the generic compare ic Marking as undetectable makes abstract equality of null, undefined, and other undetectable objects easier. Supporting it in the generic compare IC significantly speeds up dynamic comparison between those values and JSReceivers by not falling back to the runtime. MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com> Review URL: https://codereview.chromium.org/1683643002 Cr-Commit-Position: refs/heads/master@{#33858}
-
- 09 Feb, 2016 1 commit
-
-
bmeurer authored
By now only the default %TypedArray%.prototype.sort compare function and the JS implementation of SameValueZero were still using the odd %_IsMinusZero intrinsic, whose semantics both included a number check (actually HeapNumber test) plus testing if the heap number stores the special -0 value. In both cases we already know that we deal with number so we can reduce it to a simple number test for -0, which can be expressed via dividing 1 by that value and checking the sign of the result. In case of the compare function, we can be even smarter and work with the reciprocal values in case x and y are equal to 0 (although long term we should probably rewrite the fast case for the typed array sorting function in C++ anyway, which will be way, way faster than our handwritten callback-style, type-feedback polluted JS implementation). R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1680783002 Cr-Commit-Position: refs/heads/master@{#33833}
-
- 08 Feb, 2016 3 commits
-
-
mstarzinger authored
The flag in question is a debug-only flag supported by full-codegen and Crankshaft only. In it's current form there are some unresolved issues: - The flag is defeated by inlining in Crankshaft. - The flag is not supported by TurboFan. - The flag is not supported by Ignition. Instead of addressing the above issues and increasing maintenance cost for all backends and also given the "slim" test coverage, this CL fully removes the support from all backends. R=bmeurer@chromium.org,jkummerow@chromium.org Review URL: https://codereview.chromium.org/1676263002 Cr-Commit-Position: refs/heads/master@{#33817}
-
bmeurer authored
This allows us to remove the somewhat awkward BuildLoadObjectField from the AstGraphBuilder and also allows us to simplify fullcodegen for class literals. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1679813002 Cr-Commit-Position: refs/heads/master@{#33815}
-
bmeurer authored
Replace the somewhat awkward RestParamAccessStub, which would always call into the runtime anyway with a proper FastNewRestParameterStub, which is basically based on the code that was already there for strict arguments object materialization. But for rest parameters we could optimize even further (leading to 8-10x improvements for functions with rest parameters), by fixing the internal formal parameter count: Every SharedFunctionInfo has a formal_parameter_count field, which specifies the number of formal parameters, and is used to decide whether we need to create an arguments adaptor frame when calling a function (i.e. if there's a mismatch between the actual and expected parameters). Previously the formal_parameter_count included the rest parameter, which was sort of unfortunate, as that meant that calling a function with only the non-rest parameters still required an arguments adaptor (plus some other oddities). Now with this CL we fix, so that we do no longer include the rest parameter in that count. Thereby checking for rest parameters is very efficient, as we only need to check whether there is an arguments adaptor frame, and if not create an empty array, otherwise check whether the arguments adaptor frame has more parameters than specified by the formal_parameter_count. The FastNewRestParameterStub is written in a way that it can be directly used by Ignition as well, and with some tweaks to the TurboFan backends and the CodeStubAssembler, we should be able to rewrite it as TurboFanCodeStub in the near future. Drive-by-fix: Refactor and unify the CreateArgumentsType which was different in TurboFan and Ignition; now we have a single enum class which is used in both TurboFan and Ignition. R=jarin@chromium.org, rmcilroy@chromium.org TBR=rossberg@chromium.org BUG=v8:2159 LOG=n Review URL: https://codereview.chromium.org/1676883002 Cr-Commit-Position: refs/heads/master@{#33809}
-
- 05 Feb, 2016 3 commits
-
-
jarin authored
This change should unify handling of finally blocks in Turbofan's AstGraphBuilder and in full-code. This should enable smooth deoptimization from finally blocks. Review URL: https://codereview.chromium.org/1663323003 Cr-Commit-Position: refs/heads/master@{#33780}
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ ) Reason for revert: Must revert for now due to chromium api natives issues. Original issue's description: > Type Feedback Vector lives in the closure > > (RELAND: the problem before was a missing write barrier for adding the code > entry to the new closure. It's been addressed with a new macro instruction > and test. The only change to this CL is the addition of two calls to > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. > And Benedikt reviewed it as well. > > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org > > BUG= > > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5 > Cr-Commit-Position: refs/heads/master@{#33741} TBR=bmeurer@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/1670813005 Cr-Commit-Position: refs/heads/master@{#33766}
-
neis authored
The recently introduced desugaring of yield* renders this code dead. BUG= Review URL: https://codereview.chromium.org/1648773003 Cr-Commit-Position: refs/heads/master@{#33762}
-
- 04 Feb, 2016 3 commits
-
-
adamk authored
Adds a new runtime function, %DefineDataPropertyInLiteral, which takes a fifth argument specifying whether the property and value are syntactically such that the value is a function (or class) literal that should have its name set at runtime. The new runtime call also allows us to eliminate the now-redundant %DefineClassMethod runtime function. This should get much less ugly once we can desugar the "dynamic" part of object literals in the parser (but that work is currently blocked on having a performant way of desugaring literals). BUG=v8:3699, v8:3761 LOG=n Review URL: https://codereview.chromium.org/1626423003 Cr-Commit-Position: refs/heads/master@{#33756}
-
neis authored
Note: This is currently only used by yield*, we still need to support it in other places (such as for-of loops). It can be used manually of course. (This CL does not touch the full-codegen implementation of yield* because that code is already dead. The yield* desugaring already supports return and doesn't need to be touched.) BUG=v8:3566 LOG=y Review URL: https://codereview.chromium.org/1639343005 Cr-Commit-Position: refs/heads/master@{#33744}
-
mvstanton authored
(RELAND: the problem before was a missing write barrier for adding the code entry to the new closure. It's been addressed with a new macro instruction and test. The only change to this CL is the addition of two calls to __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. And Benedikt reviewed it as well. TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1668103002 Cr-Commit-Position: refs/heads/master@{#33741}
-
- 02 Feb, 2016 1 commit
-
-
bmeurer authored
There's no point in having %_IsFunction as inline intrinsic, as it is only used in non performance critical code, which is already full of runtime calls anyway, so %IsFunction will do the trick as well. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1658123002 Cr-Commit-Position: refs/heads/master@{#33660}
-
- 29 Jan, 2016 1 commit
-
-
bmeurer authored
If we deoptimize from TurboFan or Crankshaft into the body of a for-in loop and that for-in mode then switches to slow mode (i.e. has to call %ForInFilter), we have to record that feedback, because otherwise we might actually OSR into that loop assuming that it's fast mode still, or even worse recompile the function later when we call it again w/o having rerun the for-in loop in fullcodegen from the beginning (where was previously the only place we could learn). R=mstarzinger@chromium.org BUG=v8:3650 LOG=n Review URL: https://codereview.chromium.org/1638303008 Cr-Commit-Position: refs/heads/master@{#33612}
-
- 28 Jan, 2016 1 commit
-
-
neis authored
The body of a generator function can now refer to the generator's input value via a new "function.sent" expression. We extend the proposal at https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md in the obvious way to also apply to GeneratorResumeAbrupt. This will enable us to desugar yield*. The new syntax is behind a new --harmony-function-sent flag. BUG=v8:4700 LOG=n Review URL: https://codereview.chromium.org/1620253003 Cr-Commit-Position: refs/heads/master@{#33574}
-
- 27 Jan, 2016 1 commit
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ ) Reason for revert: Bug: failing to use write barrier when writing code entry into closure. Original issue's description: > Reland of Type Feedback Vector lives in the closure > > (Fixed a bug found by nosnap builds.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > BUG= > > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1 > Cr-Commit-Position: refs/heads/master@{#33548} TBR=bmeurer@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/1643533003 Cr-Commit-Position: refs/heads/master@{#33556}
-