1. 25 Feb, 2016 1 commit
  2. 24 Feb, 2016 2 commits
  3. 23 Feb, 2016 2 commits
  4. 19 Feb, 2016 3 commits
    • jarin's avatar
      Revert of [turbofan] Connect ObjectIsNumber to effect and control chains.... · 2ae5894d
      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}
      2ae5894d
    • jarin's avatar
      [turbofan] Connect ObjectIsNumber to effect and control chains. · 2894e80a
      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}
      2894e80a
    • bmeurer's avatar
      [turbofan] Remove the JSContextRelaxation reducer. · 8a7186b8
      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}
      8a7186b8
  5. 17 Feb, 2016 3 commits
  6. 16 Feb, 2016 3 commits
  7. 15 Feb, 2016 3 commits
  8. 14 Feb, 2016 1 commit
  9. 12 Feb, 2016 2 commits
    • epertoso's avatar
      [turbofan] Fix a bug in the RawMachineAssembler · 61a4c528
      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}
      61a4c528
    • bmeurer's avatar
      [runtime] Introduce FastNewStrictArgumentsStub to optimize strict arguments. · 09d84535
      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}
      09d84535
  10. 10 Feb, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Make InterpreterAssembler a subclass of CodeStubAssembler. · d1c28849
      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}
      d1c28849
  11. 09 Feb, 2016 2 commits
  12. 08 Feb, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Introduce JSCreateLowering for optimizing JSCreate nodes. · 07e9921f
      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}
      07e9921f
    • bmeurer's avatar
      [runtime] Optimize and unify rest parameters. · 3ef573e9
      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}
      3ef573e9
  13. 05 Feb, 2016 1 commit
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of... · 3f36e658
      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}
      3f36e658
  14. 04 Feb, 2016 2 commits
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · bb31db3a
      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}
      bb31db3a
    • mtrofin's avatar
      [turbofan] fine grained in-block move optimization · 1ecf58f4
      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}
      1ecf58f4
  15. 02 Feb, 2016 4 commits
    • bmeurer's avatar
      [turbofan] Move creation stub fallbacks to JSGenericLowering. · 7be58299
      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}
      7be58299
    • bmeurer's avatar
      [turbofan] Introduce proper ObjectIsReceiver operator. · 6b2001b6
      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}
      6b2001b6
    • bmeurer's avatar
      [intrinsics] Remove %_IsFunction inline intrinsic. · 8c04a35c
      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}
      8c04a35c
    • jarin's avatar
      Remove the template magic from types.(h|cc), remove types-inl.h. · ef35f11c
      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}
      ef35f11c
  16. 29 Jan, 2016 3 commits
    • ahaas's avatar
      [turbofan] Add the StackSlot operator to turbofan. · 64588037
      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}
      64588037
    • ahaas's avatar
      Revert of [turbofan] Add the StackSlot operator to turbofan. (patchset #4... · 11f7c2e6
      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}
      11f7c2e6
    • ahaas's avatar
      [turbofan] Add the StackSlot operator to turbofan. · 7a693437
      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}
      7a693437
  17. 27 Jan, 2016 3 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of... · a7027851
      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}
      a7027851
    • mvstanton's avatar
      Reland of Type Feedback Vector lives in the closure · d984b3b0
      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}
      d984b3b0
    • oth's avatar
      [interpreter] Reduce move operations for wide register support. · 95bec7e7
      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}
      95bec7e7
  18. 26 Jan, 2016 2 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of... · e2e7dc32
      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}
      e2e7dc32
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · a5200f7e
      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}
      a5200f7e