Add bytecode for defining data properties, which initially just calls the runtime function.
BUG=v8:5624
Review-Url: https://codereview.chromium.org/2510743002
Cr-Commit-Position: refs/heads/master@{#41101}
The reasons are:
1) The names dictionaries in the feedback metadata seems to consume a lot of memory
and the idea didn't payoff.
2) The absence of a name parameter blocks data handlers support in LoadGlobalIC.
This CL reverts a part of r37278 (https://codereview.chromium.org/2096653003/).
BUG=chromium:576312, v8:5561
Review-Url: https://codereview.chromium.org/2510653002
Cr-Commit-Position: refs/heads/master@{#41046}
SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
- The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
- The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
The following additional changes were necessary:
- The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
- The class HPositionInfo was effectively dead code and is now removed.
- SourcePosition has new printing and information facilities, including computing a full inlining stack.
- I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
- I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
- I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
- Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
BUG=v8:5432
Review-Url: https://codereview.chromium.org/2451853002
Cr-Commit-Position: refs/heads/master@{#40975}
We seem to get some small wins from avoiding the Ldr bytecodes, probably due
to reduced icache pressure since there are less bytecode handlers. Replace
the Ldr bytecodes with Star lookahead inlined into the Lda versions.
Also fixes IsAccumulatorLoadWithoutEffects to include LdaContextSlot and
LdaCurrentContextSlot
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2489513005
Cr-Commit-Position: refs/heads/master@{#40883}
The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when
inlining accessors in TurboFan. Remove them and replace with a Star lookahead
in the bytecode handlers for Lda[Named/Keyed]Property.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2485383002
Cr-Commit-Position: refs/heads/master@{#40860}
This removes the first stack check in inlined functions in the bytecode
graph builder, to match the behaviour of the AST graph builder.
I measure a ~1% statistically significant (p < 0.01) improvement on
Mandreel with --ignition-staging --turbo (on my x64 machine, YMMV).
Review-Url: https://codereview.chromium.org/2392333002
Cr-Commit-Position: refs/heads/master@{#40715}
The majority of context slot accesses are to the local context (current context
register and depth 0), so this adds bytecodes to optimise for that case.
This cuts down bytecode size by roughly 1% (measured on Octane and Top25).
Review-Url: https://codereview.chromium.org/2459513002
Cr-Commit-Position: refs/heads/master@{#40641}
This is a new bytecode which behaves (for now) exactly like Call,
except that in turbofan graph building we can set the
ConvertReceiverMode to NotNullOrUndefined.
I observe a 1% improvement on Box2D, I'd expect a similar improvement on
other OOP heavy code.
Review-Url: https://codereview.chromium.org/2450243002
Cr-Commit-Position: refs/heads/master@{#40610}
This makes the creation of frame states "before" and "after" node
sequences explicit in the {BytecodeGraphBuilder}. This removes some
complexity and also allows us to ellide redundant {Checkpoint} nodes
before operations that don't actually eager deoptimize.
In this change such redundant {Checkpoint} nodes have been removed for
arguments object and rest array creation bytecodes. The frame states
used in such {Checkpoint} nodes were actually bogus because they would
resume bytecode execution before the {new.target} value is assigned to
its respective variable.
R=jarin@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2437683003
Cr-Commit-Position: refs/heads/master@{#40453}
Adds a fast-path test and branch for the turbofan graph generated by
BytecodeGraphBuilder for dynamic global lookups.
BUG=v8:5263
Review-Url: https://codereview.chromium.org/2374983003
Cr-Commit-Position: refs/heads/master@{#39882}
Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup
variables that can be globally loaded, without calling the runtime, as long as
there was no context extension by a sloppy eval along their context chain.
BUG=v8:5263
Review-Url: https://codereview.chromium.org/2347143002
Cr-Commit-Position: refs/heads/master@{#39537}
Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup
variables that can be context loaded, without calling the runtime, as
long as there was no context extension by a sloppy eval along their
context chain.
BUG=v8:5263
Review-Url: https://codereview.chromium.org/2343633002
Cr-Commit-Position: refs/heads/master@{#39473}
Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).
Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.
Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).
See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8
BUG=v8:5267,v8:5372
R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2337123003
Cr-Commit-Position: refs/heads/master@{#39410}
Extract the call counts from the type feedback vector during graph
building (either via the AstGraphBuilder or the BytecodeGraphBuilder),
and put them onto the JSCallFunction and JSCallConstruct operators,
so that they work even across inlinine through .apply and .call (which
was previously hacked by creating a temporary type feedback vector
for those).
The next logic step will be to make those call counts into real
relative call frequencies (also during graph building), so that we
can make inlining decisions that make sense for the function being
optimized (where absolute values are misleading).
R=jarin@chromium.org
BUG=v8:5267,v8:5372
Review-Url: https://codereview.chromium.org/2330883002
Cr-Commit-Position: refs/heads/master@{#39400}
This makes sure OSR entry points can be added without having special
{OsrPoll} instructions in the bytecode stream. Eventually we might end
up merging back-branches and OSR polls together. Any loop header can be
used as an OSR entry point.
R=bmeurer@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2329933003
Cr-Commit-Position: refs/heads/master@{#39373}
This is analogous to the variable liveness analysis we do in the AstGraphBuilder, but on the bytecode registers.
BUG=
Review-Url: https://codereview.chromium.org/2307863002
Cr-Commit-Position: refs/heads/master@{#39248}
Avoid the useless strict equality comparisons with true/false being
generated for the JumpIfTrue, JumpIfFalse, JumpIfToBooleanTrue and
JumpIfToBooleanFalse bytecodes. Instead feed the accumulator (or the
outcome of ToBoolean) directly to the Branch node and do the negation
as part of the control flow.
The previous subraphs would render the loop variable analysis useless,
and would cause a lot of unnecessary bit materialization, because many
of our optimizations don't kick in.
Note: This is only part of the problem, there are more subtle differences
in the bytecode pipeline that prevent several important optimizations to
kick in.
R=mstarzinger@chromium.org
BUG=v8:5267,v8:5348
Review-Url: https://codereview.chromium.org/2309733002
Cr-Commit-Position: refs/heads/master@{#39151}
This way, many files which only need CompilationInfo but not compiler.h
and its dependencies can include just compilation-info.h.
BUG=
Review-Url: https://codereview.chromium.org/2284313003
Cr-Commit-Position: refs/heads/master@{#39038}
Drive-by fix: the order of parameters in the BinaryOpWithFeedback TurboFan code stubs now reflects the convention of having the context at the end.
BUG=v8:5273
Review-Url: https://codereview.chromium.org/2263253002
Cr-Commit-Position: refs/heads/master@{#38832}
Collect type feedback for subtract operation in interpreter. Also use it in
bytecode-graph-bulder to set the correct Hint for subtract operation.
BUG=v8:5273
LOG=N
Review-Url: https://codereview.chromium.org/2221833002
Cr-Commit-Position: refs/heads/master@{#38467}
This completely removes translation of exception handler predictions
from the graph IR. We now rely on the runtime using deoptimization
infomation via {FrameSummary} for predictions in optimized code.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2207533002
Cr-Commit-Position: refs/heads/master@{#38250}
This gets rid of the Star bytecodes that were always dispatched to from
ToObject.
ToObject now outputs to register instead of to the accumulator and
ForInPrepare gets the receiver object from an input register.
BUG=v8:4820
LOG=n
Review-Url: https://codereview.chromium.org/2189463006
Cr-Commit-Position: refs/heads/master@{#38177}
This implements graph construction for entry via on-stack replacement
within the {BytecodeGraphBuilder}. Entry points are at loop headers
similar to previous OSR implementations. All interpreter registers are
addressable via {OsrValue} nodes in the graph. Currently we rely on
{OsrPoll} bytecodes to be placed right after loop headers (i.e. at the
targets of back edges).
R=jarin@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2171083004
Cr-Commit-Position: refs/heads/master@{#38083}
ToName was always generated with a subsequent Star, fuse them.
Requires a few changes in the peephole optimizer as ToName cannot be
elided as easily, but must be replaced by Star.
BUG=v8:4280
LOG=n
Review-Url: https://codereview.chromium.org/2169813002
Cr-Commit-Position: refs/heads/master@{#38019}
Reason for revert:
Breaks the roll, possibly win gn:
https://codereview.chromium.org/2148863002/
Original issue's description:
> [interpreter] Reduce dependencies in bytecodes.{h,cc}
>
> This CL reduces the number of dependencies bytecodes.{h,cc} to facilitate
> generating the bytecode peephole optimizer table during build. Specifically,
> it avoids depending on v8_base.
>
> BUG=v8:4280
> LOG=N
>
> Committed: https://crrev.com/4edebb1cd870ae6c1359ad54f83e618e185883b1
> Cr-Commit-Position: refs/heads/master@{#37715}
TBR=mstarzinger@chromium.org,rmcilroy@chromium.org,oth@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2151693003
Cr-Commit-Position: refs/heads/master@{#37743}
This CL reduces the number of dependencies bytecodes.{h,cc} to facilitate
generating the bytecode peephole optimizer table during build. Specifically,
it avoids depending on v8_base.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/2135273002
Cr-Commit-Position: refs/heads/master@{#37715}
Introduces fused bytecodes for fusing LdaSmi followed by a binary op bytecode.
The chosen bytecodes are used frequently in Octane: AddSmi, SubSmi,
BitwiseOrSmi, BitwiseAndSmi, ShiftLeftSmi, ShiftRightSmi.
There are additional code stubs for these operations that are biased towards
both the left hand and right hand operands being Smis.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/2111923002
Cr-Commit-Position: refs/heads/master@{#37531}
This change introduces five fused bytecodes for common bytecode
sequences on popular websites. These are LdrNamedProperty,
LdrKeyedProperty, LdrGlobal, LdrContextSlot, and LdrUndefined. These
load values into a destination register operand instead of the
accumulator. They are emitted by the peephole optimizer.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/1985753002
Cr-Commit-Position: refs/heads/master@{#36507}
It's always possible to deoptimize to Ignition from TurboFan, and we
don't use Ignition for asm.js code, so there's no need to have the empty
frame state magic in the BytecodeGraphBuilder.
R=mstarzinger@chromium.org
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2008243002
Cr-Commit-Position: refs/heads/master@{#36505}
Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call.
BUG=v8:4822
LOG=y
Review URL: https://codereview.chromium.org/1645763003
Cr-Commit-Position: refs/heads/master@{#34983}
This change introduces wide prefix bytecodes to support wide (16-bit)
and extra-wide (32-bit) operands. It retires the previous
wide-bytecodes and reduces the number of operand types.
Operands are now either scalable or fixed size. Scalable operands
increase in width when a bytecode is prefixed with wide or extra-wide.
The bytecode handler table is extended to 256*3 entries. The
first 256 entries are used for bytecodes with 8-bit operands,
the second 256 entries are used for bytecodes with operands that
scale to 16-bits, and the third group of 256 entries are used for
bytecodes with operands that scale to 32-bits.
LOG=N
BUG=v8:4747,v8:4280
Review URL: https://codereview.chromium.org/1783483002
Cr-Commit-Position: refs/heads/master@{#34955}
Reason for revert:
It is not a good idea to call CallICStub from the builtin. It might be sensitive to the frame structure. Constructing a internal frame might cause problems. It is much better to inline the code related to the type feedback vector into the builtin.
Original issue's description:
> [Interpreter] Implements calls through CallICStub in the interpreter.
>
> Calls are implemented through CallICStub to collect type feedback. Adds
> a new builtin called InterpreterPushArgsAndCallIC that pushes the
> arguments onto stack and calls CallICStub.
>
> Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
> go through CallICStub.
>
> MIPS port contributed by balazs.kilvady.
>
> BUG=v8:4280, v8:4680
> LOG=N
>
> Committed: https://crrev.com/20362a2214c11a0f2ea5141b6a79e09458939cec
> Cr-Commit-Position: refs/heads/master@{#34244}
TBR=rmcilroy@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280, v8:4680
Review URL: https://codereview.chromium.org/1731253003
Cr-Commit-Position: refs/heads/master@{#34252}
Calls are implemented through CallICStub to collect type feedback. Adds
a new builtin called InterpreterPushArgsAndCallIC that pushes the
arguments onto stack and calls CallICStub.
Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
go through CallICStub.
MIPS port contributed by balazs.kilvady.
BUG=v8:4280, v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1688283003
Cr-Commit-Position: refs/heads/master@{#34244}
This CL introduces two new bytecodes TailCall and TailCallWide.
BUG=v8:4698,v8:4687
LOG=N
Review URL: https://codereview.chromium.org/1698273003
Cr-Commit-Position: refs/heads/master@{#34083}
This removes the CompilationInfo field from the BytecodeGraphBuilder
class. The intention is to reduce the risk of using uninitialized or
unavailable values from the CompilationInfo (e.g. values that are only
available after parsing).
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1704913002
Cr-Commit-Position: refs/heads/master@{#34081}
Adds support for ES6 super keyword and performing loads, stores, and
calls to super class members.
Implements SetHomeObject and enables ThisFunctionVariable.
BUG=v8:4280,v8:4682
LOG=N
Review URL: https://codereview.chromium.org/1689573004
Cr-Commit-Position: refs/heads/master@{#33977}
Adds JumpIfNotHoleConstant and JumpIfNotHoleConstantWide bytecodes
and removes JumpIfHole bytecode.
In situations with large numbers of constants, the generator would
fail because an 8-bit constant could not be reserved for
JumpIfHole/JumpIfNotHole and so a 16-bit constant would be reserved.
Then when patching the bytecode the patcher would discover there was
no wide constant variant of the emitted jump.
BUG=v8:4280,v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1697473002
Cr-Commit-Position: refs/heads/master@{#33952}
Reason for revert:
No fix needed, original CL was perfectly fine!
Original issue's description:
> Revert of [interpreter] Correctly thread through catch prediction. (patchset #1 id:1 of https://codereview.chromium.org/1690973002/ )
>
> Reason for revert:
> Depends on the reverted https://codereview.chromium.org/1691723002
>
> Original issue's description:
> > [interpreter] Correctly thread through catch prediction.
> >
> > This change correctly sets the {CatchPrediction} field in exception
> > handler tables for bytecode and optimized code. It also adds tests
> > independent of promise handling for this prediction, to ensure all our
> > backends are in sync on their prediction.
> >
> > R=rmcilroy@chromium.org,yangguo@chromium.org
> > TEST=mjsunit/compiler/debug-catch-prediction
> > BUG=v8:4674
> > LOG=n
> >
> > Committed: https://crrev.com/ba55f5594cb0b4a1a1e9b35d87fe54afe2d93f3b
> > Cr-Commit-Position: refs/heads/master@{#33906}
>
> TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4674
>
> Committed: https://crrev.com/c5229b311968fd638a6cd537c341b1055eb7be97
> Cr-Commit-Position: refs/heads/master@{#33922}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4674
Review URL: https://codereview.chromium.org/1689113004
Cr-Commit-Position: refs/heads/master@{#33933}
Reason for revert:
Depends on the reverted https://codereview.chromium.org/1691723002
Original issue's description:
> [interpreter] Correctly thread through catch prediction.
>
> This change correctly sets the {CatchPrediction} field in exception
> handler tables for bytecode and optimized code. It also adds tests
> independent of promise handling for this prediction, to ensure all our
> backends are in sync on their prediction.
>
> R=rmcilroy@chromium.org,yangguo@chromium.org
> TEST=mjsunit/compiler/debug-catch-prediction
> BUG=v8:4674
> LOG=n
>
> Committed: https://crrev.com/ba55f5594cb0b4a1a1e9b35d87fe54afe2d93f3b
> Cr-Commit-Position: refs/heads/master@{#33906}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4674
Review URL: https://codereview.chromium.org/1695613002
Cr-Commit-Position: refs/heads/master@{#33922}
This change correctly sets the {CatchPrediction} field in exception
handler tables for bytecode and optimized code. It also adds tests
independent of promise handling for this prediction, to ensure all our
backends are in sync on their prediction.
R=rmcilroy@chromium.org,yangguo@chromium.org
TEST=mjsunit/compiler/debug-catch-prediction
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1690973002
Cr-Commit-Position: refs/heads/master@{#33906}
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}
This threads the language mode from the bytecode to the node creation
site in the bytecode graph builder. It only adapts the places where such
threading is applicable without considering strong mode. The remaining
uses of the language mode accessors are only required because of strong
mode.
R=mythria@chromium.org
Review URL: https://codereview.chromium.org/1678103004
Cr-Commit-Position: refs/heads/master@{#33852}
This allows us to remove the somewhat awkward BuildLoadObjectField
from the BytecodeGraphBuilder and also allows us to simplify the
bytecode stream for class literals.
R=oth@chromium.org
Review URL: https://codereview.chromium.org/1678103002
Cr-Commit-Position: refs/heads/master@{#33820}
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.orgTBR=rossberg@chromium.org
BUG=v8:2159
LOG=n
Review URL: https://codereview.chromium.org/1676883002
Cr-Commit-Position: refs/heads/master@{#33809}
