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}

of non-pattern expressions, according to the (internally circulated)
design document.  Details to be provided here.

1.  RewritableAssignmentExpression has been renamed to RewritableExpression.
    It is a wrapper for AST nodes that wait for some potential rewriting
    (that may or may not happen).  Also, Is... and As... macros now see
    through RewritableExpressions.

2.  The function state keeps a list of rewritable expressions that must be
    rewritten only if they are used as non-pattern expressions.

3.  Expression classifiers are now templates, parameterized by parser
    traits.  They keep some additional state: a pointer to the list of
    non-pattern rewritable expressions.  It is important that expression
    classifiers be used strictly in a stack fashion, from now on.

4.  The RewriteNonPattern function has been simplified.

BUG=chromium:579913
LOG=N

Committed: https://crrev.com/7f5c864a6faf2b957b7273891e143b9bde35487c
Cr-Commit-Position: refs/heads/master@{#34154}

Review URL: https://codereview.chromium.org/1702063002

Cr-Commit-Position: refs/heads/master@{#34162}

Revert of Non-pattern rewriting revisited (patchset #3 id:40001 of https://codereview.chromium.org/1702063002/ )

Reason for revert:
[Sheriff] This makes jsfunfuzz unhappy:
https://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/7681

Original issue's description:
> This patch implements an alternative approach to the rewriting
> of non-pattern expressions, according to the (internally circulated)
> design document.  Details to be provided here.
>
> 1.  RewritableAssignmentExpression has been renamed to RewritableExpression.
>     It is a wrapper for AST nodes that wait for some potential rewriting
>     (that may or may not happen).  Also, Is... and As... macros now see
>     through RewritableExpressions.
>
> 2.  The function state keeps a list of rewritable expressions that must be
>     rewritten only if they are used as non-pattern expressions.
>
> 3.  Expression classifiers are now templates, parameterized by parser
>     traits.  They keep some additional state: a pointer to the list of
>     non-pattern rewritable expressions.  It is important that expression
>     classifiers be used strictly in a stack fashion, from now on.
>
> 4.  The RewriteNonPattern function has been simplified.
>
> BUG=chromium:579913
> LOG=N
>
> Committed: https://crrev.com/7f5c864a6faf2b957b7273891e143b9bde35487c
> Cr-Commit-Position: refs/heads/master@{#34154}

TBR=rossberg@chromium.org,bmeurer@chromium.org,titzer@chromium.org,nikolaos@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:579913

Review URL: https://codereview.chromium.org/1712203002

Cr-Commit-Position: refs/heads/master@{#34158}

of non-pattern expressions, according to the (internally circulated)
design document.  Details to be provided here.

1.  RewritableAssignmentExpression has been renamed to RewritableExpression.
    It is a wrapper for AST nodes that wait for some potential rewriting
    (that may or may not happen).  Also, Is... and As... macros now see
    through RewritableExpressions.

2.  The function state keeps a list of rewritable expressions that must be
    rewritten only if they are used as non-pattern expressions.

3.  Expression classifiers are now templates, parameterized by parser
    traits.  They keep some additional state: a pointer to the list of
    non-pattern rewritable expressions.  It is important that expression
    classifiers be used strictly in a stack fashion, from now on.

4.  The RewriteNonPattern function has been simplified.

BUG=chromium:579913
LOG=N

Review URL: https://codereview.chromium.org/1702063002

Cr-Commit-Position: refs/heads/master@{#34154}

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}

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}

This CL adds a TRACE_EVENT where there is an isolated LOG, a HistogramTimer
or a TimerEvent.

Once we have a d8 tracing controller, all TimerEvents will be removed since
they do not provide an added value over TRACE_EVENTs. HistogramTimers will
remain, but their functionality will be limited to Histograms only.

BUG=v8:4562
LOG=N

Review URL: https://codereview.chromium.org/1707563002

Cr-Commit-Position: refs/heads/master@{#34099}

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}

Port 0d595bb0

Original commit message:
    It's fine to only have the runtime call here, as it's only used in the
    debug mirror.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1707683002

Cr-Commit-Position: refs/heads/master@{#34085}

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}

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}

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}

  port e0129d0f (r33986)

  original commit message:
  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.

BUG=

Review URL: https://codereview.chromium.org/1701983004

Cr-Commit-Position: refs/heads/master@{#34062}

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}

  port 09d84535(r33925)

  original commit message:
  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.

BUG=

Review URL: https://codereview.chromium.org/1706703002

Cr-Commit-Position: refs/heads/master@{#34055}

  port e519e6fa(r33886)

  original commit message:
  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=

Review URL: https://codereview.chromium.org/1706673002

Cr-Commit-Position: refs/heads/master@{#34054}

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}

R=bmeurer@chromium.org
BUG=v8:3956
LOG=n

Review URL: https://codereview.chromium.org/1693833002

Cr-Commit-Position: refs/heads/master@{#34036}

The LazyBailout operator (modelled as a nop-call) was introduced for
placing a deoptimization point into exception handlers. Now that we are
no longer re-entering lazy deoptimized code, the support can be removed.

R=jarin@chromium.org
BUG=v8:4195
LOG=n

Review URL: https://codereview.chromium.org/1697503002

Cr-Commit-Position: refs/heads/master@{#34020}

  port 4ff159bd(r33880)

  original commit message:
  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.

BUG=

Review URL: https://codereview.chromium.org/1694343002

Cr-Commit-Position: refs/heads/master@{#34012}

Port e0129d0f

Original commit message:
    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=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1699923002

Cr-Commit-Position: refs/heads/master@{#34005}

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}

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}

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}

  port 3ef573e9(r33809)

  original commit message:
  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.

BUG=

Review URL: https://codereview.chromium.org/1696063002

Cr-Commit-Position: refs/heads/master@{#33971}

Port 09d84535

Original commit message:
    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=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1696743002

Cr-Commit-Position: refs/heads/master@{#33963}

Port e519e6fa

Original commit message:
    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.

R=ishell@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4698
LOG=N

Review URL: https://codereview.chromium.org/1690953003

Cr-Commit-Position: refs/heads/master@{#33951}

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}

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}

The idea here is to perform the handler lookup in the deoptimizer, and then take the information from the handler table to build the catch handler frame in the deoptimizer. Specifically, we use the pc offset, context location and stack height (in full-code) to tweak the output frame.

Sadly, this still requires nasty voodoo for the liveness analyzer so that it keeps variables alive if they are used in the catch handler.

Review URL: https://codereview.chromium.org/1416543006

Cr-Commit-Position: refs/heads/master@{#33936}

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}

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}

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}

PPC: Mark null and undefined as undetectable, and use it to handle abstract equality comparison in the generic compare ic

Port 3ce9e808

Original commit message:
    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.

R=verwaest@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1684133003

Cr-Commit-Position: refs/heads/master@{#33876}

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}

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}

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1675383002

Cr-Commit-Position: refs/heads/master@{#33831}

Port 3ef573e9

Original commit message:
    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
    xwhich is used in both TurboFan and Ignition.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:2159
LOG=n

Review URL: https://codereview.chromium.org/1677223002

Cr-Commit-Position: refs/heads/master@{#33829}

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}

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}