- 25 Feb, 2016 1 commit
-
-
ahaas authored
Comparison operators are lowered using to a lexicographic ordering, e.g. (a,b) <= (c,d) <<>> (a < c) | (a == c) & (b <= d). R=titzer@chromium.org Review URL: https://codereview.chromium.org/1729263002 Cr-Commit-Position: refs/heads/master@{#34287}
-
- 24 Feb, 2016 2 commits
-
-
ahaas authored
(a EQ b) is lowered to ((low(a) XOR low(b)) OR (high(a) XOR high(b))) EQ 0 R=titzer@chromium.org Review URL: https://codereview.chromium.org/1729493002 Cr-Commit-Position: refs/heads/master@{#34249}
-
ahaas authored
R=titzer@chromium.org Review URL: https://codereview.chromium.org/1723613002 Cr-Commit-Position: refs/heads/master@{#34241}
-
- 23 Feb, 2016 2 commits
-
-
ahaas authored
R=titzer@chromium.org Review URL: https://codereview.chromium.org/1716243002 Cr-Commit-Position: refs/heads/master@{#34219}
-
ahaas authored
R=titzer@chromium.org Review URL: https://codereview.chromium.org/1714793003 Cr-Commit-Position: refs/heads/master@{#34213}
-
- 19 Feb, 2016 3 commits
-
-
jarin authored
Revert of [turbofan] Connect ObjectIsNumber to effect and control chains. (patchset #1 id:1 of https://codereview.chromium.org/1709093002/ ) Reason for revert: Tanks benchmarks (e.g., Octane box2d TF). Original issue's description: > [turbofan] Connect ObjectIsNumber to effect and control chains. > > In theory, we could connect the nodes when doing > the schedule-in-the-middle pass, but that would require creating two > versions of the operator (effectful and pure). I believe we do not > lose anything by wiring the node up eagerly. > > Committed: https://crrev.com/2894e80a0a4a51a0d72e72aa48fcd01968f7949f > Cr-Commit-Position: refs/heads/master@{#34141} TBR=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/1718483002 Cr-Commit-Position: refs/heads/master@{#34147}
-
jarin authored
In theory, we could connect the nodes when doing the schedule-in-the-middle pass, but that would require creating two versions of the operator (effectful and pure). I believe we do not lose anything by wiring the node up eagerly. Review URL: https://codereview.chromium.org/1709093002 Cr-Commit-Position: refs/heads/master@{#34141}
-
bmeurer authored
This reducer doesn't really add value, because: (a) it is only concerned with JSCallFunction and JSToNumber, but when we get to it, all JSCallFunction nodes will have been replaced by Call nodes, and in the not so far future, we will also have replaced almost all JSToNumber nodes with better code, (b) and the reducer tries to be smart and use one of the outermost contexts, but that might not be beneficial always; actually it might even create longer live ranges and lead to more spilling in some cases. But most importantly, the JSContextRelaxation currently blocks inlining based on SharedFunctionInfo, because it requires the inliner to check the native context, which in turn requires JSFunction knowledge. So I'm removing this reducer for now to unblock the more important inliner changes. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1715633002 Cr-Commit-Position: refs/heads/master@{#34139}
-
- 17 Feb, 2016 3 commits
-
-
mstarzinger authored
This removes the language mode parameter from all JSCall operators. The information is no longer used anywhere and is not threaded through the interpreter bytecode. We should only thread it through the bytecode if it has a semantic impact on the compilation. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1709493002 Cr-Commit-Position: refs/heads/master@{#34073}
-
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 3 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}
-
martyn.capewell authored
Support SBFX in the instruction selector for sign-extension patterns like Sar(Shl(x, a), b), where a and b are immediate values. BUG= Review URL: https://codereview.chromium.org/1695293002 Cr-Commit-Position: refs/heads/master@{#34029}
-
- 15 Feb, 2016 3 commits
-
-
titzer authored
Passing floating point params to/from C has never quite worked correctly, but we've never enforced the restriction early in the CallDescriptor creation process because of unittests. Fix unittests to make their own simple call descriptors and not rely on the C ones. R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1701593003 Cr-Commit-Position: refs/heads/master@{#33993}
-
martyn.capewell authored
Improve instruction selector for mask and shift operations by using cheaper instructions where possible, in preference to UBFX. Reverted because it was suspected of causing a couple of flaky tests to fail, but investigation suggests this is unlikely. Original review: https://codereview.chromium.org/1677023002 BUG= Review URL: https://codereview.chromium.org/1684073006 Cr-Commit-Position: refs/heads/master@{#33988}
-
bmeurer authored
This adds initial support for inline allocation of object and array literals to the JSCreateLowering pass. It's basically identical to what Crankshaft does. This also unstages the TurboFan escape analysis, as the lowering seems to trigger a bunch of bugs in it; those bugs will be fixed separately, and we will re-enable escape analysis afterwards. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1698783002 Cr-Commit-Position: refs/heads/master@{#33972}
-
- 14 Feb, 2016 1 commit
-
-
titzer authored
R=jarin@chromium.org BUG= Review URL: https://codereview.chromium.org/1691373002 Cr-Commit-Position: refs/heads/master@{#33966}
-
- 12 Feb, 2016 2 commits
-
-
epertoso authored
This was causing code like: REX.W cmpq r9,r8 setzl r8l movzxbl r8,r8 REX.W cmpq r8,0x0 jz 185 (note the cmpq instead of cmpl above) on x64 instead of: REX.W cmpq r9,r8 jnz 149 http://crrev.com/1677503002 is now obsolete and has been reverted. Review URL: https://codereview.chromium.org/1685183003 Cr-Commit-Position: refs/heads/master@{#33934}
-
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}
-
- 10 Feb, 2016 1 commit
-
-
rmcilroy authored
Moves InterpreterAssembler out of the compiler directory and into the interpreter directory. Makes InterpreterAssembler as subclass of CodeStubAssembler. As part of this change, the special bytecode dispatch linkage type is removed and instead we use a InterfaceDispatchDescriptor and a normal CodeStub linkage type. Removes a bunch of duplicated logic in InterpreterAssembler and instead uses the CodeStubAssembler logic. Refactors Interpreter with these changes. Modifies CodeStubAssembler to add the extra operations required by the Interpreter (extra call types, raw memory access and some extra binary ops). Also adds the ability for subclasses to add extra prologue and epilogue operations around calls, which is required for the Interpreter. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1673333004 Cr-Commit-Position: refs/heads/master@{#33873}
-
- 09 Feb, 2016 2 commits
-
-
martyn.capewell authored
Revert of [turbofan] ARM: Improve AND instruction selection (patchset #1 id:1 of https://codereview.chromium.org/1677023002/ ) Reason for revert: Possibly causing Mozilla test failures - will investigate. Original issue's description: > [turbofan] ARM: Improve AND instruction selection > > Improve instruction selector for mask and shift operations by using cheaper > instructions where possible, in preference to UBFX. > > BUG= > > Committed: https://crrev.com/53d9c12977f07f55b6f2a72128b8d02c4c857845 > Cr-Commit-Position: refs/heads/master@{#33843} TBR=bmeurer@chromium.org,jarin@chromium.org,danno@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/1681953003 Cr-Commit-Position: refs/heads/master@{#33850}
-
martyn.capewell authored
Improve instruction selector for mask and shift operations by using cheaper instructions where possible, in preference to UBFX. BUG= Review URL: https://codereview.chromium.org/1677023002 Cr-Commit-Position: refs/heads/master@{#33843}
-
- 08 Feb, 2016 2 commits
-
-
bmeurer authored
This moves the JSCreate related functionality from JSTypedLowering into a dedicated JSCreateLowering reducer. This is in preparation of landing the support for optimized literals in TurboFan, which would blow up JSTypedLowering quite seriously otherwise. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1678833002 Cr-Commit-Position: refs/heads/master@{#33813}
-
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 1 commit
-
-
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}
-
- 04 Feb, 2016 2 commits
-
-
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}
-
mtrofin authored
So far, we've been moving down gaps wholesale. This change moves individual move operations instead. This improves some benchmarks, and should overall reduce code size, because it improves the chance of reducing the number of moves. For example, there are improvements on x64 in Emscripten (Bullet, in particular) , JetStream geomean, Embenchen (zlib). In the process of making this change, I noticed we can separate the tasks performed by the move optimizer, as follows: - group gaps into 1 - push gaps down, jumping instructions (these 2 were together before) - merge blocks (and then push gaps down) - finalize We can do without a finalization list. This avoids duplicating storage - we already have the list of instructions; it also simplifies the logic, since, with this change, we may process an instruction's gap twice. Compile time doesn't regress much (see pathological cases), but we may want to avoid the allocations of the few sets used in the new code. I'll do that in a subsequent change. BUG= Review URL: https://codereview.chromium.org/1634093002 Cr-Commit-Position: refs/heads/master@{#33715}
-
- 02 Feb, 2016 4 commits
-
-
bmeurer authored
Move all the code that deals with falling back to object creation via stubs to JSGenericLowering, where we can already deal well with stub calls. This includes JSCreateLiteralArray, JSCreateLiteralObject, JSCreateClosure, JSCreateFunctionContext and JSCreateArray. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1653353002 Cr-Commit-Position: refs/heads/master@{#33682}
-
bmeurer authored
Avoid the hacking in JSIntrinsicLowering and provide a proper simplified operator ObjectIsReceiver instead that is used to implement %_IsJSReceiver which is used by our JavaScript builtins and the JSInliner. R=jarin@chromium.org BUG=v8:4544 LOG=n Review URL: https://codereview.chromium.org/1657863004 Cr-Commit-Position: refs/heads/master@{#33675}
-
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}
-
jarin authored
This CL removes the Config templatization from the types. It is not necessary anymore, after the HeapTypes have been removed. The CL also changes the type hierarchy - the specific type kinds are not inner classes of the Type class and they do not inherit from Type. This is partly because it seems impossible to make this work without templates. Instead, a new TypeBase class is introduced and all the structural (i.e., non-bitset) types inherit from it. The bitset type still requires the bit-munging hack and some nasty reinterpret-casts to pretend bitsets are of type Type*. Additionally, there is now the same hack for TypeBase - all pointers to the sub-types of TypeBase are reinterpret-casted to Type*. This is to keep the type constructors in inline method definitions (although it is unclear how much that actually buys us). In future, we would like to move to a model where we encapsulate Type* into a class (or possibly use Type where we used to use Type*). This would loosen the coupling between bitset size and pointer size, and eventually we would be able to have more bits. TBR=bradnelson@chromium.org Review URL: https://codereview.chromium.org/1655833002 Cr-Commit-Position: refs/heads/master@{#33656}
-
- 29 Jan, 2016 3 commits
-
-
ahaas authored
The StackSlot operator allows to allocate a spill slot on the stack. We are going to use this operator to pass floats through pointers to c functions, which we need for floating point rounding in the case where the architecture does not provide rounding instructions. R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223 Cr-Commit-Position: refs/heads/master@{#33600} Review URL: https://codereview.chromium.org/1645653002 Cr-Commit-Position: refs/heads/master@{#33606}
-
ahaas authored
Revert of [turbofan] Add the StackSlot operator to turbofan. (patchset #4 id:60001 of https://codereview.chromium.org/1645653002/ ) Reason for revert: problems on Mac64 Original issue's description: > [turbofan] Add the StackSlot operator to turbofan. > > The StackSlot operator allows to allocate a spill slot on the stack. We > are going to use this operator to pass floats through pointers to c > functions, which we need for floating point rounding in the case where > the architecture does not provide rounding instructions. > > R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com > > Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223 > Cr-Commit-Position: refs/heads/master@{#33600} TBR=titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1644283002 Cr-Commit-Position: refs/heads/master@{#33601}
-
ahaas authored
The StackSlot operator allows to allocate a spill slot on the stack. We are going to use this operator to pass floats through pointers to c functions, which we need for floating point rounding in the case where the architecture does not provide rounding instructions. R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com Review URL: https://codereview.chromium.org/1645653002 Cr-Commit-Position: refs/heads/master@{#33600}
-
- 27 Jan, 2016 3 commits
-
-
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}
-
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}
-
oth authored
Introduces the concept of transfer direction to register operands. This enables the register translator to emit exactly the moves that a bytecode having it's register operands translated needs. BUG=v8:4280,v8:4675 LOG=N Review URL: https://codereview.chromium.org/1633153002 Cr-Commit-Position: refs/heads/master@{#33544}
-
- 26 Jan, 2016 2 commits
-
-
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}
-