This patch correctly re-scopes inner scopes that can appear in do
expressions used as initializers to arrow parameters.
R=rossberg@chromium.org
BUG=v8:4904
LOG=N
Review URL: https://codereview.chromium.org/1887743002
Cr-Commit-Position: refs/heads/master@{#35542}
Currently we are using UnsafeCurrent in async signal handler to acquire the
isolate of VM thread, but we want to get rid of that since it prevents V8 from
being thread agnostic.
This patch replaces UnsafeCurrent with a static map, where we store a map of
samplers for threads, and makes it accessible by signal handler.
BUG=v8:4889
LOG=n
Review URL: https://codereview.chromium.org/1858143003
Cr-Commit-Position: refs/heads/master@{#35541}
Runtime_OptimizeFunctionOnNextCall and Runtime_DeoptimizeFunction asserts that
the argument is a JSFunction object.These are used by fuzzers to get coverage
of optimizations in compiler. Having an assert causes a fuzzer test to fail
when OptimizeFunctionOnNextCall is called on objects that are not functions.
We can instead, silently return on such calls.
BUG=chromium:601391
LOG=N
Review URL: https://codereview.chromium.org/1883603002
Cr-Commit-Position: refs/heads/master@{#35539}
Port 5e9ddf6ce4
Original commit message:
* New atomic code stubs for x64, ia32, arm, arm64
* Add convenience functions JumpIfNotValidSmiValue, JumpIfUintNotValidSmiValue
to macro-assembler-ia32 (API based on x64 macro assembler)
* Remove runtime implementation of Atomics.load, the code stub should always be
called instead
* Add new test to mjsunit atomics test; check that Smi values of different
sizes are supported when possible, else fall back to HeapNumbers
These changes were needed to add another codestub:
* Bump kStubMajorKeyBits from 7 to 8
* Reduce ScriptContextFieldStub::kSlotIndexBits from 13 to 12
R=binji@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=v8:4614
LOG=N
Review URL: https://codereview.chromium.org/1882733008
Cr-Commit-Position: refs/heads/master@{#35537}
Port 0c05e02f25
Original commit message:
Modifies Ignition to store code entry addresses in the dispatch table
rather than code objects. This allows the interpreter to avoid
calculating the code entry address from the code object on every
dispatch and provides a ~5-7% performance improvement on Octane with
Ignition.
This change adds ArchOpcode::kArchTailCallAddress to TurboFan to enable
tail call dispatch using these code addresses. It also adds a Dispatch
linkage creator (distinct from the stub linkage type used previously) to
allow targetting a code address target (which will diverge further from
the stub linkage type when we remove the context machine register in
Ignition).
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1887263003
Cr-Commit-Position: refs/heads/master@{#35533}
This hoists all bailouts out of OptimizedCompileJob::CreateGraph into
the compiler pipeline. The reason is that this moves them to a point
where we can still influence the decision which compiler to pick and
hence gives us more freedom with modeling various pipelines.
R=neis@chromium.org
Review URL: https://codereview.chromium.org/1883313003
Cr-Commit-Position: refs/heads/master@{#35532}
Usually, script compilation is expensive enough to warrant the extra
overhead of caching scripts immediatly.
BUG=chromium:588900
R=yangguo@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1890083002
Cr-Commit-Position: refs/heads/master@{#35527}
This adds an ObjectIsString operator and hooks it up with
JSNativeContextSpecialization (to remove the use of some machine
operators there).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1894523002
Cr-Commit-Position: refs/heads/master@{#35525}
PersistentValueMap is used to hold per-world wrappers in the blink. Currently,
when we trace wrappers, we visit wrappers in all worlds via this PersistentValueMap. This cl introduces convenient (and faster) way of registering these external references.
BUG=468240
LOG=no
Review URL: https://codereview.chromium.org/1883043003
Cr-Commit-Position: refs/heads/master@{#35523}
port 6df9a22c3f (r35187)
original commit message:
The HandlerCompiler did not properly handle the weird edge case when a
sloppy mode function was installed as an accessor on one of the value
wrapper prototypes and then accessed via a load from a primitive value.
In this case we just passed the primitive value untouched instead of
properly wrapping it first. The CallFunction builtin properly deals with
all the funny edge cases, so we use it instead of duplicating almost all
of the logic here (the performance difference is neglible).
BUG=
Review URL: https://codereview.chromium.org/1884293003
Cr-Commit-Position: refs/heads/master@{#35522}
This prefixes the escape analysis flag with "experimental", thereby
making sure the flag in question is not being fuzzed. It will reduce
noise levels on ClusterFuzz again.
R=jarin@chromium.org
BUG=chromium:603653
LOG=n
Review URL: https://codereview.chromium.org/1894513002
Cr-Commit-Position: refs/heads/master@{#35521}
This moves the responsibility of preparing full-codegen code with
deoptimization support into the backends. This avoids generating such
code when optimization can be done directly from existing bytecode.
R=bmeurer@chromium.org
BUG=v8:4280
LOG=n
Review URL: https://codereview.chromium.org/1883403002
Cr-Commit-Position: refs/heads/master@{#35517}
We have trouble with Math.fround(MEM[...]). Since we now properly type
LoadBuffer (it can produce undefined), lowering of fround has stopped
triggering (as it requires Number type). This CL is a quick fix for this issue
- we simply trigger the lowering for NumberOrUndefined and let representation
selection/truncation analysis deal with this.
Ultimately, we would want to insert some 'simplified' ToNumber conversion
that would be optimized as much as possible during representation
selection.
BUG=chromium:603802
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1893483003
Cr-Commit-Position: refs/heads/master@{#35513}
The current context is stored as a stack slot on the interpreter frame
and therefore we don't need to also maintain a machine register for the
context. Removes this register from bytecode handlers.
In the process modifies this frees up a register on ia32 to keep the
dispatch table pointer in a register rather than on a stack slot on
ia32.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1887493004
Cr-Commit-Position: refs/heads/master@{#35511}
port 974721c661 (r35283)
original commit message:
Introduce a ResumeGeneratorTrampoline, which does the actual stack state
reconstruction (currently always restores a fullcodegen frame), and
introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
%GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
this native builtin.
Also unify the flooding in case of step-in to always work based on
JSFunction and remove the special casing for JSGeneratorObject.
BUG=
Review URL: https://codereview.chromium.org/1889083002
Cr-Commit-Position: refs/heads/master@{#35510}
port 3dd3beb066 (r35199)
original commit message:
Currently, if the size of two cmp or test operands is a byte or a word, we sign-extend or zero-extend each of them into a 32-bit register before doing the comparison, even when the conditions
for the use of a memory operand are met.
This CL makes it possible to load only one of them into a register and address the other as a memory operand.
The tricky bit is that, unlike as in the x64 counterpart http://crrev.com/1780193003, not all registers can be accessed as bytes.
BUG=
Review URL: https://codereview.chromium.org/1883373002
Cr-Commit-Position: refs/heads/master@{#35508}
The CL #35176 (https://codereview.chromium.org/1843983002) exposed one hidden bug in x87 turbofan code generation for kX87Float64ToUint32.
The current kX87Float64ToUint32 code generation will destroy the input value in X87 FPU stack which will be used by the following code.
This CL fixed this bug.
BUG=
Review URL: https://codereview.chromium.org/1884403002
Cr-Commit-Position: refs/heads/master@{#35507}
The current code for testing the VEX.L flag, indicating whether
128-bit or 256-bit registers are being accessed, was erroneous
and always returned true (i.e. indicated 128-bit registers).
This patch fixes this behaviour and checks the flag correctly.
Ref: https://github.com/nodejs/node/issues/6151
BUG=
Review URL: https://codereview.chromium.org/1875323002
Cr-Commit-Position: refs/heads/master@{#35506}
Rolling v8/buildtools to 5378d73123b64907773cc5c1bb027b2f765ff00a
Rolling v8/tools/clang to 41bff4c5ba97022c0fe69a59d8892a6c45fb0867
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1889043002
Cr-Commit-Position: refs/heads/master@{#35505}
The builtin context is not a thing anymore. This means we don't have to
worry about being able to deserialize it when optimizing top-level code.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1891793002
Cr-Commit-Position: refs/heads/master@{#35502}
Port 0c05e02f25
Original commit message:
Modifies Ignition to store code entry addresses in the dispatch table
rather than code objects. This allows the interpreter to avoid
calculating the code entry address from the code object on every
dispatch and provides a ~5-7% performance improvement on Octane with
Ignition.
This change adds ArchOpcode::kArchTailCallAddress to TurboFan to enable
tail call dispatch using these code addresses. It also adds a Dispatch
linkage creator (distinct from the stub linkage type used previously) to
allow targetting a code address target (which will diverge further from
the stub linkage type when we remove the context machine register in
Ignition).
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1888053002
Cr-Commit-Position: refs/heads/master@{#35501}
We will move this back to start of incremental marking when we make faster progress.
Perf sheriffs: This CL may cause a regression on benchmarks that improved earlier by enabling black allocation.
BUG=chromium:599174
LOG=n
Review URL: https://codereview.chromium.org/1889853002
Cr-Commit-Position: refs/heads/master@{#35500}
This changes closure creation to lower to inline allocations when
possible instead of going through the FastNewClosureStub. It allows us
to leverage all advantages of inline allocations on closures. Note that
it is only safe to embed the raw entry point of the compile lazy stub
into the code, because that stub is immortal and immovable.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1573153002
Cr-Commit-Position: refs/heads/master@{#35499}
