This CL simplifies the relation between the wasm graph builder, the
wasm decoder, and the wasm module they work on.
BUG=
Review-Url: https://codereview.chromium.org/2612643002
Cr-Commit-Position: refs/heads/master@{#42056}
-- Removes remaning debug from promise.js and moves it to c++
-- Changes debug_id to be a smi in PromiseReactionJobInfo and
PromiseResolveThenableJobInfo.
-- Changes debug_name to be a smi in PromiseReactionJobInfo and
PromiseResolveThenableJobInfo.
-- Adds PromiseDebugActionName and PromiseDebugActionType enums
-- Adds PromiseDebugActionNameToString and
PromiseDebugActionTypeToString helper methods
-- Changes variable `status` to be int in runtime functions.
-- Changes debug_id to start from 1, not 0 for easier bookkeeping.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2606093002
Cr-Commit-Position: refs/heads/master@{#42052}
These maps contain exactly the same information as the strict maps, so
this frees up a few pointers of native context space, gets rid of some
branches in FastNewClosure, and adds missing poisoned properties tests
for async functions.
BUG=v8:2355, v8:4483
R=adamk@chromium.org, bmeurer@chromium.org, littledan@chromium.org
Review-Url: https://codereview.chromium.org/2608333002
Cr-Commit-Position: refs/heads/master@{#42051}
Port 72c3707672
Original Commit Message:
Currently the CompileLazy builtin checks the SFI expliciltly for FCG code. This means
if the SFI has bytecode we have to go through to the runtime to install the
interpreter entry trampoline into the JSFunction object.
Modify the builtin to always put the SFI code object into the JSFunction unless it's
the lazy compile stub on the SFI as well.
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4380
LOG=N
Review-Url: https://codereview.chromium.org/2602383003
Cr-Commit-Position: refs/heads/master@{#42046}
The previous patch for this bug (https://codereview.chromium.org/2599793002/) was wrong because it changed the behavior of isCreatedPhi() in an incompatible way. The actual source of the bug is that escape analysis propagates information along cycles without considering the previous analysis value. This fix makes sure that if a previous merge cleared a field, then it stays cleared.
R=bmeurer@chromium.org
BUG=chromium:670202
Review-Url: https://codereview.chromium.org/2610703002
Cr-Commit-Position: refs/heads/master@{#42045}
MarkCompactCollector::Prepare is too early in the rare case that we don't have a
marking deque yet. EnterFinalPause could then trigger
Heap::RegisterExternallyReferencedObject which rightfully fails because MC is
not properly set up.
Note that the DCHECK also triggers, without actual consequences, for aborting
incremental marking.
BUG=468240
TBR=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2611753002
Cr-Commit-Position: refs/heads/master@{#42044}
Tracks background compilation of Ignition in a separate bucket from main thread
compilation. Also add some more compilation buckets for functions which can take a
significant proportion of compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2577263002
Cr-Original-Commit-Position: refs/heads/master@{#42026}
Committed: b0e9116d59
Review-Url: https://codereview.chromium.org/2577263002
Cr-Commit-Position: refs/heads/master@{#42042}
Currently the CompileLazy builtin checks the SFI expliciltly for FCG code. This means
if the SFI has bytecode we have to go through to the runtime to install the
interpreter entry trampoline into the JSFunction object.
Modify the builtin to always put the SFI code object into the JSFunction unless it's
the lazy compile stub on the SFI as well.
BUG=v8:4380
Review-Url: https://codereview.chromium.org/2583693003
Cr-Commit-Position: refs/heads/master@{#42034}
When baselining a function using the BaselineFunctionOnNextCall intrinsic, it is
not always ensured that a function is already compiled. Update the
Runtime_BaselineFunctionOnNextCall function to trigger a compile if it is not already
compiled.
BUG=v8:5768
Review-Url: https://codereview.chromium.org/2594543003
Cr-Commit-Position: refs/heads/master@{#42033}
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/13358
Original issue's description:
> [Compiler] Track Ignition background compilation separately in RuntimeStats.
>
> Tracks background compilation of Ignition in a separate bucket from main thread
> compilation. Also add some more compilation buckets for functions which can take a
> significant proportion of compilation.
>
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2577263002
> Cr-Commit-Position: refs/heads/master@{#42026}
> Committed: b0e9116d59TBR=jochen@chromium.org,cbruni@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2609773003
Cr-Commit-Position: refs/heads/master@{#42031}
Migrate Date.prototype.valueOf and Date.prototype[ @@toPrimitive ]
to use the CodeStubAssembler, to avoid going through C++ always
when comparing or subtracting two dates.
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2608143003
Cr-Commit-Position: refs/heads/master@{#42030}
(Missing includes discovered during the objects.h splitting work.)
BUG=v8:5402
Review-Url: https://codereview.chromium.org/2610643002
Cr-Commit-Position: refs/heads/master@{#42029}
Tracks background compilation of Ignition in a separate bucket from main thread
compilation. Also add some more compilation buckets for functions which can take a
significant proportion of compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2577263002
Cr-Commit-Position: refs/heads/master@{#42026}
The heap traversal for SFI code objects when logging compiled functions
was previously accessing the abstract code of an SFI, logging its
bytecode if it exists or code object otherwise. However, there are some
(rare) cases where an SFI has both bytecode and a non-interpreter code
object -- for example, after baseline tier-up -- in which case we want
to log both, as both could be executing (at different points on the
stack).
BUG=v8:5758
Review-Url: https://codereview.chromium.org/2603333002
Cr-Commit-Position: refs/heads/master@{#42025}
Changes some for loops to use node->inputs() instead of iterating over
InputCount and accessing InputAt(i). This saves some checks for
"has_inline_inputs" and so some branches.
Review-Url: https://codereview.chromium.org/2585713002
Cr-Commit-Position: refs/heads/master@{#42024}
Don't fallback to the %StrictEqual / %Equal runtime functions for the
generic CompareIC slow path, but use the (new) StrictEqual and Equal
builtins instead. This avoids a performance cliff when mixing input
types for strict equality sites.
R=jochen@chromium.org
BUG=v8:4773
Review-Url: https://codereview.chromium.org/2609153002
Cr-Commit-Position: refs/heads/master@{#42021}
port 05873add85 (r41989)
original commit message:
The following ported to builtins:
FastCloneRegExp
FastCloneShallowArray
FastCloneShallowObject
BUG=
Review-Url: https://codereview.chromium.org/2607383002
Cr-Commit-Position: refs/heads/master@{#42020}
port 5b02a98bfa (r41986)
original commit message:
In the process, convert from a code stub into a builtin.
BUG=
Review-Url: https://codereview.chromium.org/2608203002
Cr-Commit-Position: refs/heads/master@{#42018}
port be11812c53 (r41971)
original commit message:
Recognize and emit in-memory comparisons of 8-bit and 16-bit values with
immediate values that fit.
BUG=
Review-Url: https://codereview.chromium.org/2612503002
Cr-Commit-Position: refs/heads/master@{#42017}
The ControlEquivalence cannot deal with new nodes inserted by the
Scheduler due to Node splitting. Rather when the ControlEquivalence
sees such a new Node, it'll likely crash on an out-of-bounds access.
This is a speculative fix to make the crash disappear, as there's no
100% reliable repro currently.
BUG=chromium:629398
TBR=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2611603002
Cr-Commit-Position: refs/heads/master@{#42016}
Hook up TurboFan with the existing field type tracking machinery to
eliminate redundant map checks on the results of LoadField operators.
The store side is already implemented in TurboFan for quite some time,
this just adds the load part.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2604393002
Cr-Commit-Position: refs/heads/master@{#42015}
- Adds CodeAssembler::ConstructJS() to simplify calling JS functions as
constructors, used by NewPromiseCapability()
- Defines PromiseCapability as a special JSObject subclass, with a
non-exensible Map, and read-only non-configurable DataDescriptors which
point to its in-object fields. This allows its fields to be used by JS
builtins until there is no longer any need.
Currently, the performance benefit comes from
https://codereview.chromium.org/2567033003/, but does not appear to
regress performance in any significant way.
BUG=v8:5343
TBR=ulan@chromium.org
Review-Url: https://codereview.chromium.org/2567333002
Cr-Commit-Position: refs/heads/master@{#42014}
We need to report cached wrappers within v8 to the embedder after each atomic
phase of v8 marking because the embedder can invalidate the wrappers in-between
v8 marking steps.
E.g., in Chrome, a conservative GC might need to wipe dead wrappables from
the wrapper tracing marking deque.
BUG=chromium:676700, chromium:468240
Review-Url: https://codereview.chromium.org/2610563002
Cr-Commit-Position: refs/heads/master@{#42011}
Store maps on the CheckMaps operator instead of burning inputs for
the individual maps. Use the same data structure (the ZoneHandleSet)
in the LoadElimination to track multiple maps per object.
BUG=v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2431563002
Cr-Commit-Position: refs/heads/master@{#42010}
