- 06 Feb, 2016 1 commit
-
-
zhengxing.li authored
port 334d1794 (r33780) original commit message: This change should unify handling of finally blocks in Turbofan's AstGraphBuilder and in full-code. This should enable smooth deoptimization from finally blocks. BUG= Review URL: https://codereview.chromium.org/1675003002 Cr-Commit-Position: refs/heads/master@{#33794}
-
- 05 Feb, 2016 9 commits
-
-
mbrandy authored
Port 334d1794 Original commit message: This change should unify handling of finally blocks in Turbofan's AstGraphBuilder and in full-code. This should enable smooth deoptimization from finally blocks. R=jarin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1669373002 Cr-Commit-Position: refs/heads/master@{#33792}
-
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}
-
mstarzinger authored
This makes the field in question more generic by renaming it from the previous "depth" to "data". Pure refactoring, no function change. R=rmcilroy@chromium.org,yangguo@chromium.org Review URL: https://codereview.chromium.org/1670983003 Cr-Commit-Position: refs/heads/master@{#33779}
-
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}
-
mvstanton authored
Revert of PPC: Type Feedback Vector lives in the closure (patchset #1 id:1 of https://codereview.chromium.org/1671553002/ ) Reason for revert: issues with chromium api natives, must revert for now, thanks. Original issue's description: > PPC: Type Feedback Vector lives in the closure > > Port bb31db3a > > Original commit message: > (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. > > R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com > BUG= > > Committed: https://crrev.com/753ad25efa4790ea7c80aceecfa223c3436ca36f > Cr-Commit-Position: refs/heads/master@{#33753} TBR=joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com # 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/1673623002 Cr-Commit-Position: refs/heads/master@{#33765}
-
mvstanton authored
Revert of X87: Type Feedback Vector lives in the closure. (patchset #1 id:1 of https://codereview.chromium.org/1672643002/ ) Reason for revert: Bugs with chromium api natives, must revert for now. Original issue's description: > X87: Type Feedback Vector lives in the closure. > > port bb31db3a (r33741) > > original commit message: > (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. > > BUG= > > Committed: https://crrev.com/25bfba9329b93cb8ebefe1446e024005a4227a93 > Cr-Commit-Position: refs/heads/master@{#33759} TBR=chunyang.dai@intel.com,weiliang.lin@intel.com,zhengxing.li@intel.com # 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/1673613002 Cr-Commit-Position: refs/heads/master@{#33764}
-
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}
-
zhengxing.li authored
port dbd86408 (r33744) original commit message: 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= Review URL: https://codereview.chromium.org/1671783002 Cr-Commit-Position: refs/heads/master@{#33760}
-
zhengxing.li authored
port bb31db3a (r33741) original commit message: (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. BUG= Review URL: https://codereview.chromium.org/1672643002 Cr-Commit-Position: refs/heads/master@{#33759}
-
- 04 Feb, 2016 5 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}
-
mbrandy authored
Port dbd86408 Original commit message: 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.) R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:3566 LOG=y Review URL: https://codereview.chromium.org/1664413002 Cr-Commit-Position: refs/heads/master@{#33754}
-
mbrandy authored
Port bb31db3a Original commit message: (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. R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1671553002 Cr-Commit-Position: refs/heads/master@{#33753}
-
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}
-
- 01 Feb, 2016 1 commit
-
-
adamk authored
A class's name is its constructor's name, so there's no need to treat it separately, either in the parser or in code generation. The main parser use of the name is for ES2015 Function.name handling, and this patch also cleans up handling there by adding a new IsAnonymousFunctionDefinition() method to Expression (the name comes from the spec). Also removed unused ParserTraits::DefaultConstructor method. BUG=v8:3699 LOG=n Review URL: https://codereview.chromium.org/1647213002 Cr-Commit-Position: refs/heads/master@{#33643}
-
- 29 Jan, 2016 4 commits
-
-
mbrandy authored
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1650593002 Cr-Commit-Position: refs/heads/master@{#33620}
-
mbrandy authored
StoreP needs a scratch register for unaligned immediate offset. R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:4700 LOG=n Review URL: https://codereview.chromium.org/1644863005 Cr-Commit-Position: refs/heads/master@{#33619}
-
mbrandy authored
Port 0637f5f6 Original commit message: 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=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:3650 LOG=n Review URL: https://codereview.chromium.org/1644383002 Cr-Commit-Position: refs/heads/master@{#33617}
-
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 6 commits
-
-
mstarzinger authored
This cleans up the aforementioned predicate to not rely on the flags computed for communication between compiled code and the runtime. The underlying predicates of the AST are used directly instead. R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1638353002 Cr-Commit-Position: refs/heads/master@{#33559}
-
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}
-
zhengxing.li authored
port 6131ab1e (r33509) original commit message: This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan. When debugger is active tail calls are disabled. Tail calling can be enabled by --harmony-tailcalls flag. BUG= Review URL: https://codereview.chromium.org/1637163003 Cr-Commit-Position: refs/heads/master@{#33549}
-
mvstanton authored
(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= Review URL: https://codereview.chromium.org/1642613002 Cr-Commit-Position: refs/heads/master@{#33548}
-
mvstanton authored
BUG= R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1638333002 Cr-Commit-Position: refs/heads/master@{#33546}
-
neis authored
In a generator function, the parser rewrites a return statement into a "final" yield. A final yield used to close the generator, which was incorrect because the return may occur inside a try-finally clause and so the generator may not yet terminate. BUG= Review URL: https://codereview.chromium.org/1634553002 Cr-Commit-Position: refs/heads/master@{#33537}
-
- 26 Jan, 2016 5 commits
-
-
mbrandy authored
Port 6131ab1e Original commit message: This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan. When debugger is active tail calls are disabled. Tail calling can be enabled by --harmony-tailcalls flag. R=ishell@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:4698 LOG=Y Review URL: https://codereview.chromium.org/1635823003 Cr-Commit-Position: refs/heads/master@{#33524}
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ ) Reason for revert: FAilure on win32 bot, need to investigate webkit failures. Original issue's description: > Type Feedback Vector lives in the closure > > 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/a5200f7ed4d11c6b882fa667da7a1864226544b4 > Cr-Commit-Position: refs/heads/master@{#33518} TBR=bmeurer@chromium.org,akos.palfi@imgtec.com # 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/1632993003 Cr-Commit-Position: refs/heads/master@{#33520}
-
mvstanton authored
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= Review URL: https://codereview.chromium.org/1563213002 Cr-Commit-Position: refs/heads/master@{#33518}
-
rmcilroy authored
Adds support for calling native function literals. Moves the logic for building the native function's SharedFunctionInfo out of full-codegen into compiler.cc to allow it to be shared between fullcodegen and Ignition. BUG=v8:4686 LOG=N Review URL: https://codereview.chromium.org/1635553002 Cr-Commit-Position: refs/heads/master@{#33510}
-
ishell authored
This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan. When debugger is active tail calls are disabled. Tail calling can be enabled by --harmony-tailcalls flag. BUG=v8:4698 LOG=Y TBR=rossberg@chromium.org Review URL: https://codereview.chromium.org/1609893003 Cr-Commit-Position: refs/heads/master@{#33509}
-
- 25 Jan, 2016 3 commits
-
-
bmeurer authored
Cleanup %ForInPrepare runtime entry, and unify common logic with %ForInEnumerate (renamed from %GetPropertyNamesFast). Also introduce a TupleType to properly type JSForInPrepare and its projections w/o special hacks in the Typer. And fix %ForInNext and JSForInNext to be consistent with fullcodegen again (after the proxy refactorings last quarter). R=jarin@chromium.org BUG=v8:3650 LOG=n Review URL: https://codereview.chromium.org/1631583002 Cr-Commit-Position: refs/heads/master@{#33487}
-
zhengxing.li authored
port a0878333(r33460) original commit message: We already had hand-written optimized code for %_ToName in fullcodegen, but the optimizing compilers always went to the runtime for %_ToName, which is pretty bad for many of our builtins. So this CL moves the existing native code to a ToNameStub (similar to the existing ToStringStub), and uses the ToNameStub consistently in all compilers to actually implement %_ToName. BUG= Review URL: https://codereview.chromium.org/1622793006 Cr-Commit-Position: refs/heads/master@{#33483}
-
bmeurer authored
Now TurboFan always uses the newly introduced %ForInPrepare, no matter whether baseline is the interpreter or fullcodegen. For fullcodegen, we introduce a new PrepareId bailout point for this purpose. Drive-by-fix: Avoid the NoObservableSideEffectsScope in Crankshaft and use the PrepareId bailout point instead. R=jarin@chromium.org BUG=v8:3650 LOG=n Review URL: https://codereview.chromium.org/1630523002 Cr-Commit-Position: refs/heads/master@{#33480}
-
- 22 Jan, 2016 2 commits
-
-
mbrandy authored
Port a0878333 Original commit message: We already had hand-written optimized code for %_ToName in fullcodegen, but the optimizing compilers always went to the runtime for %_ToName, which is pretty bad for many of our builtins. So this CL moves the existing native code to a ToNameStub (similar to the existing ToStringStub), and uses the ToNameStub consistently in all compilers to actually implement %_ToName. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1620313004 Cr-Commit-Position: refs/heads/master@{#33476}
-
bmeurer authored
We already had hand-written optimized code for %_ToName in fullcodegen, but the optimizing compilers always went to the runtime for %_ToName, which is pretty bad for many of our builtins. So this CL moves the existing native code to a ToNameStub (similar to the existing ToStringStub), and uses the ToNameStub consistently in all compilers to actually implement %_ToName. Review URL: https://codereview.chromium.org/1622493002 Cr-Commit-Position: refs/heads/master@{#33460}
-
- 21 Jan, 2016 2 commits
-
-
mbrandy authored
Port f48bf12f Original commit message: The PrepareId bailout location was used incorrectly in Crankshaft and, as it turns out, is not required anyway (once you do it right). Also there was some premature optimization going on with the CheckEnumCache (trying to load null from roots only once), plus we can be smarter about the null/undefined check anyway. The idea behind this changes is to prepare unification of the two different ForInPrepare implementations that we now have, with the end result being that we only use the new implementation that was recently added for the interpreter. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:3650 LOG=n Review URL: https://codereview.chromium.org/1619643004 Cr-Commit-Position: refs/heads/master@{#33447}
-
balazs.kilvady authored
BUG= Review URL: https://codereview.chromium.org/1605093002 Cr-Commit-Position: refs/heads/master@{#33430}
-