This CL also replaces some Branch() usages with GotoIf/GotoUnless.
BUG=v8:2743
LOG=Y
Review-Url: https://codereview.chromium.org/1995453002
Cr-Commit-Position: refs/heads/master@{#36657}
When we moved the String.fromCharCode builtin to C++, we slightly
regressed the fast single character code argument case. Recovered some
of the performance by implementing the builtin using the TurboFan
CodeStubAssembler.
Drive-by-fix: Make sure the stack trace from the implicit ToNumber
conversion in String.fromCharCode includes the builtin by adding a
regression test for that.
R=yangguo@chromium.org
BUG=chromium:609831,chromium:613947,v8:5049
Review-Url: https://codereview.chromium.org/2021143003
Cr-Commit-Position: refs/heads/master@{#36611}
Previously, CodeStubAssembler macros performing FixedArray element accesses had
to compute offsets to elements explicitly with a fair amount of duplicated
code. Furthermore, any peephole optimizations that could produce better code--
like recognizing constant indices or combining array index computation with Smi
untagging--were also duplicated.
This change factors the code to compute FixedArray index offsets into a common
routine in the CodeStubAssembler that applies standard peephole optimizations to
all accesses. In order to do this, it also introduces limited introspection into
the up-until-now opaque Node* type exported from code-assembler.h, allowing
Nodes to be queried whether they are constant and extracting their constant
value in that case.
Review-Url: https://codereview.chromium.org/1989363004
Cr-Commit-Position: refs/heads/master@{#36370}
This adds back the instanceof operator support in the backends and
introduces a @@hasInstance protector cell on the isolate that guards the
fast path for the InstanceOfStub. This way we recover the ~10%
regression on Octane EarleyBoyer in Crankshaft and greatly improve
TurboFan and Ignition performance of instanceof.
R=ishell@chromium.orgTBR=hpayer@chromium.org,rossberg@chromium.org
BUG=chromium:597249, v8:4447
LOG=n
Review-Url: https://codereview.chromium.org/1980483003
Cr-Commit-Position: refs/heads/master@{#36275}
Code common with ObjectHasOwnProperty builtin was moved to CodeStubAssembler.
BUG=v8:2743
LOG=Y
Review-Url: https://codereview.chromium.org/1894953004
Cr-Commit-Position: refs/heads/master@{#35972}
Adapts FastCloneShallowObjectStub to enable it to be used by the
CreateObjectLiteral bytecode.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/1922523002
Cr-Commit-Position: refs/heads/master@{#35909}
Instead of replacing the array with an empty one after resuming, overwrite
contents with a new Oddball.
This will simplify the work to be done by the bytecode graphbuilder and
potentially allow for more optimization.
(For full-codegen generators, nothing changes.)
BUG=v8:4907
LOG=n
Review-Url: https://codereview.chromium.org/1923253002
Cr-Commit-Position: refs/heads/master@{#35872}
This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
trick that was used in the MachineOperatorReducer to combine the
ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
doing that later, we can just introduce the proper operator during the
representation selection directly.
Also separate the TruncateFloat64ToInt32 machine operator, which had two
different meanings depending on a flag (either JavaScript truncation or
C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
represents the JavaScript truncation (implemented via TruncateDoubleToI
macro + code stub) and the RoundFloat64ToInt32, which implements the C++
round towards zero operation (in the same style as the other WebAssembly
driven Round* machine operators).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1919513002
Cr-Commit-Position: refs/heads/master@{#35743}
The new bytecodes replace two runtime functions. They are still unsupported by the bytecode graphbuilder, though.
BUG=v8:4907
LOG=n
Review URL: https://codereview.chromium.org/1904933002
Cr-Commit-Position: refs/heads/master@{#35716}
This separation is needed to make two goals possible simultaneously:
* is should be possible to offer V8 components a simple, clean
interface to TurboFan's low-level code generation that doesn't
expose details about the TF.
* it should be possible to easily create new CodeAssembler "macros"
that don't require a review from an OWNER of the compiler directory.
Review URL: https://codereview.chromium.org/1875583003
Cr-Commit-Position: refs/heads/master@{#35576}
