We turn a JSCallFunction node for
f.apply(receiver, arguments)
into a JSCallForwardVarargs node, when the arguments refers to the
arguments of the outermost optimized code object, i.e. not an inlined
arguments, and the apply method refers to Function.prototype.apply,
and there's no other user of arguments except in frame states.
We also replace the arguments node in the graph with a marker for
the Deoptimizer similar to Crankshaft to make sure we don't materialize
unused arguments just for the sake of deoptimization. We plan to replace
this with a saner EscapeAnalysis based solution soon.
R=jarin@chromium.org
BUG=v8:5267,v8:5726
Review-Url: https://codereview.chromium.org/2655233002
Cr-Commit-Position: refs/heads/master@{#42680}
This makes sure that the deoptimizer preserves the exact bit pattern of
floating-point values (both 32-bit and 64-bit) up to the point where a
potential {HeapNumber} is allocated. It in turn allows us to correctly
recognize the {hole_nan_value} when stored into a {FixedDouleArray}.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-684208
BUG=chromium:684208
Review-Url: https://codereview.chromium.org/2652303002
Cr-Commit-Position: refs/heads/master@{#42679}
In practice, Emscripten seems to emit cond?+a:+b type return
expressions. This is not allowed by the spec or errata, but we need
to support it for compatibility.
Similar patterns with ints / signed, do not seem to be supported.
BUG=v8:5891
R=mtrofin@chromium.org,aseemgarg@chromium.org
Review-Url: https://codereview.chromium.org/2648353010
Cr-Commit-Position: refs/heads/master@{#42677}
Changes output from
CALL RUNTIME (context function) code = 0x3e9ea90a2049 at -1
to
CALL RUNTIME async_function_promise_create code = 0x3e9ea90a2049 at -1
This makes the ast more useful. I didn't annotate all the runtime calls,
only some for now. We can annotate others if necessary.
Review-Url: https://codereview.chromium.org/2654113002
Cr-Commit-Position: refs/heads/master@{#42671}
List of items:
1. Avoid zero-extending for subsequent 32-bit operations if current operation does not change upper 32-bit or does zero-extending.
2. Match complex address mode for binary operation where possible (eg. use Add R,MEM).
3. Detect instruction forms in selector. Eg. kAllowRRR, kAllowRM
4. Optimize sequence for Int32MulWithOverflow, Int32Div, etc.
5. Remove Not32/Not64 which is the same as XOR
R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com
BUG=
Review-Url: https://codereview.chromium.org/2649113007
Cr-Commit-Position: refs/heads/master@{#42669}
Enable enqueueing of eager inner function compilation onto the compiler
dispatcher. This enables these tasks to be performed in parallel to
compilation of the outer functio (only for Ignition functions).
We currently synchronize to ensure all inner function compilations
are complete before executing the outer function - future work will
allow outer function execution to happenin parallel to inner function
compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2611313002
Cr-Commit-Position: refs/heads/master@{#42667}
Adds CSA::Print(const char* s), which generates a runtime call to
Runtime::kGlobalPrint with a line-terminated ASCII string constant,
and CSA::DebugPrint(const char* prefix, Node* tagged_value), which
emits a runtime call to Runtime::kDebugPrint() with the tagged
value, optionally prefixed by an ascii string constant.
These simplify debugging TF builtins by providing a tool to easily
observe the contents of values at arbitrary points in a program,
without stepping endlessly through assembly in a debugger, and to
easily observe the path taken through a TF builtin.
These methods do not generate code in release builds.
BUG=v8:5268
R=ishell@chromium.org, danno@chromium.org, bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2651673003
Cr-Commit-Position: refs/heads/master@{#42660}
Also tidy some JS style in the file.
BUG=chromium:673246
NOTRY=true
Review-Url: https://codereview.chromium.org/2650353004
Cr-Commit-Position: refs/heads/master@{#42659}
We did not smi-check the spread argument here, meaning we tried to take the map
of a smi, resulting in segfaults which clusterfuzz found.
Also added tests that exercise this path.
BUG=685086
Review-Url: https://codereview.chromium.org/2655013002
Cr-Commit-Position: refs/heads/master@{#42657}
The data produced at the moment only contains information about scope type +
positions, and only the most trivial tests pass.
Upcoming CLs will extend the data to contain information about variables (once
PreParser can produce it) and add more test cases.
BUG=v8:5516
Review-Url: https://codereview.chromium.org/2650703003
Cr-Commit-Position: refs/heads/master@{#42656}
The default stack size of a background thread is 512KB on MacOSX. We default to
1MB stack checks when compiling JS code, so we need to increase this limit
to enable compilation of JS code onto background threads.
Corresponding Chromium CL is https://codereview.chromium.org/2640803002/
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2653673007
Cr-Commit-Position: refs/heads/master@{#42650}
It's a common pattern to create a Variable and immediately initialize
it. This adds a new constructor to make that pattern more natural.
BUG=
Review-Url: https://codereview.chromium.org/2657533003
Cr-Commit-Position: refs/heads/master@{#42649}
This fixes the checks of accumulator usage flags in the computation of
the interpreter register liveness during bytecode analysis. The usage
flags at hand are bit patterns as opposed to flat enum values. Use the
safe accessors instead of plain comparison.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-683581
BUG=chromium:683581
Review-Url: https://codereview.chromium.org/2651653005
Cr-Commit-Position: refs/heads/master@{#42648}
This adds support to constant-fold JSGetSuperConstructor(constructor)
for constructors with stable maps, i.e. where we can add a stability
dependency on the constructors map to get notified when the [[Prototype]]
of constructor changes.
R=petermarshall@chromium.org
BUG=v8:5517
Review-Url: https://codereview.chromium.org/2652763010
Cr-Commit-Position: refs/heads/master@{#42647}
This test checks that counters accurately reflect the allocated size.
There's an edge case that can occur when, previously to the allocation,
the page does not have enough space left to allocate the requested
object - then we move on to a fresh page, fill the remaining space of
the old page with a filler object, and allocate the requested object on
the new page.
The counters will show the size of the filler object plus the requested
object size, while the test expects only the requested size.
This CL fixes that case by performing two GCs to clear out new space.
BUG=
Review-Url: https://codereview.chromium.org/2652933002
Cr-Commit-Position: refs/heads/master@{#42646}
- kDebugPromiseCreated(task, parent_task)
This event occurs when promise is created (PromiseHookType::Init). V8Debugger uses this event to maintain task -> parent task map.
- kDebugEnqueueAsyncFunction(task)
This event occurs when first internal promise for async function is created. V8Debugger collects stack trace at this point.
- kDebugEnqueuePromiseResolve(task),
This event occurs when Promise fulfills with resolved status. V8Debugger collects stack trace at this point.
- kDebugEnqueuePromiseReject(task),
This event occurs when Promise fulfills with rejected status. V8Debugger collects stack trace at this point.
- kDebugPromiseCollected,
This event occurs when Promise is collected and no other chained callbacks can be added. V8Debugger removes information about async task for this promise.
- kDebugWillHandle,
This event occurs when chained promise function (either resolve or reject handler) is called. V8Debugger installs parent promise's stack (based on task -> parent_task map) as current if available or current promise's scheduled stack otherwise.
- kDebugDidHandle,
This event occurs after chained promise function has finished. V8Debugger restores asynchronous call chain to previous one.
With this change all instrumentation calls are related to current promise (before WillHandle and DidHandle were related to next async task).
Before V8Debugger supported only the following:
- asyncTaskScheduled(task1)
- asyncTaskStarted(task1)
- asyncTaskFinished(task1)
Now V8Debugger supports the following:
- asyncTaskScheduled(parent_task)
..
- asyncTaskCreated(task, parent_task),
- asyncTaskStarted(task), uses parent_task scheduled stack
- asyncTaskScheduled(task)
- asyncTaskFinished(task)
Additionally: WillHandle and DidHandle were migrated to PromiseHook API.
More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE
BUG=v8:5738
R=dgozman@chromium.org,gsathya@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2650803003
Cr-Commit-Position: refs/heads/master@{#42644}
In the JSCallReducer we'd inline certain builtins like the Array
constructor or Function builtins across native contexts, which at
this point should be mostly safe, but might lead to cross context
leaks in the future (as it's not obvious that the JSCallReducer)
doesn't maintain this invariant. So better safe than sorry.
R=yangguo@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2651133002
Cr-Commit-Position: refs/heads/master@{#42643}
port f9367847b0 (r42632)
original commit message:
We can share almost all of the architecture-specific builtin code with super-call-with-spread.
Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread,
in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store.
BUG=
Review-Url: https://codereview.chromium.org/2652153002
Cr-Commit-Position: refs/heads/master@{#42642}
port d287c81969 (r42620)
original commit message:
[RELAND with one change: until literal arrays are rooted in the outer
feedback vector (coming in the next days), the runtime-scope.cc change
is held off.]
When a function is declared in global scope, the closure is created
by the DeclareGlobals runtime service. It needs a pointer to the
literals array, already allocated in the feedback vector. This
fixes a bug where it's behavior wasn't in sync with CreateClosure,
which accepts the literals from the vector.
This enables a follow-on performance improvement in the CompileLazy
builtin.
BUG=
Review-Url: https://codereview.chromium.org/2653893002
Cr-Commit-Position: refs/heads/master@{#42641}
Array.prototype.concat does not properly handle JSProxy species that will
modify the currently visited array.
BUG=682194
Review-Url: https://codereview.chromium.org/2655623004
Cr-Commit-Position: refs/heads/master@{#42640}
We're converting the build_overrides system to the new default_args list of
overrides that can be listed in the toplevel .gn file. This will allow args to
be set on a per-repo basis.
This change conditionally adds the variables currently defined in
build_overrides/v8.gni to build args. This allows V8's build to be used in both
the new and old systems. Once all Chrome and pdfium have been updated, v8's
build overrides and the conditional checks around the new args can be removed.
BUG=684096
Review-Url: https://codereview.chromium.org/2654663003
Cr-Commit-Position: refs/heads/master@{#42639}
Since JumpLoop is always backwards, and other jumps are always forwards,
we can store the jump offset as an always positive integer and decide on
the jump direction based on the bytecode. This will save a small amount
of space for large-ish for loops (>128 bytecodes).
Review-Url: https://codereview.chromium.org/2641443002
Cr-Commit-Position: refs/heads/master@{#42638}
The property backing store size depends on the number of
index keys. Pass index keys to the factory function instead
calculating the size outside.
R=verwaest@chromium.org
BUG=v8:5625
Review-Url: https://codereview.chromium.org/2651533002
Cr-Commit-Position: refs/heads/master@{#42637}
Speculative reason for issue 684481.
BUG=chromium:684481
TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,
Original issue's description:
> [Parse] ParseInfo owns the parsing Zone.
>
> Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
> in preperation for enabling background compilation jobs for inner functions
> share the AST in the outer-function's parse zone memory (read-only), with the
> and zone being released when all compilation jobs have completed.
>
> BUG=v8:5203, v8:5215
> Review-Url: https://codereview.chromium.org/2632123006
> Cr-Commit-Position: refs/heads/master@{#42562}
> Committed: 4b0101d369
Review-Url: https://codereview.chromium.org/2648383005
Cr-Commit-Position: refs/heads/master@{#42633}
We can share almost all of the architecture-specific builtin code with super-call-with-spread.
Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2649143002
Cr-Commit-Position: refs/heads/master@{#42632}
