There is a print in AstNumbering which needs to dereference the string
containing the function name, which clashes with the disallowed handle
reference scope used to allow ast-numbering to run off-thread.
This could be fixed by pushing the print out of this function, and
somehow propagating disable_crankshaft_reason out of the visitor, but in
reality this check will soon be removed anyway, and until it is this
function will be on the main thread, so we may as well just hack it.
Review-Url: https://codereview.chromium.org/2653953006
Cr-Commit-Position: refs/heads/master@{#42711}
This corrects the case when we need to allocate a
blocked register, but the blockage happens after a
use as an instruction input, and there's no place to
split before that.
BUG=v8:5888
Review-Url: https://codereview.chromium.org/2652153005
Cr-Original-Commit-Position: refs/heads/master@{#42706}
Committed: ca779b29a6
Review-Url: https://codereview.chromium.org/2652153005
Cr-Commit-Position: refs/heads/master@{#42710}
This CL adds --crankshaft and --no-always-opt flags to the tests that use
assertOptimized() and assertUnoptimized() respectively.
This CL also adds presubmit checks that ensure that tests have the proper
flags set.
BUG=v8:5890
Review-Url: https://codereview.chromium.org/2653753007
Cr-Commit-Position: refs/heads/master@{#42709}
Port f9367847b0
Port bf782ec512
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.
R=petermarshall@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:5511
LOG=N
Review-Url: https://codereview.chromium.org/2655043004
Cr-Commit-Position: refs/heads/master@{#42708}
Reason for revert:
Introduces new crashers, e.g.
load("test/mjsunit/wasm/wasm-constants.js");
load("test/mjsunit/wasm/wasm-module-builder.js");
(function() {
var builder = new WasmModuleBuilder();
builder.addMemory(16, 32, false);
builder.addFunction("test", kSig_i_iii)
.addBodyWithEnd([
// body:
kExprI64Const, 0x42,
kExprI64Const, 0x7a,
kExprI64Ctz,
kExprI64Mul,
kExprI64Ctz,
kExprI64Const, 0x41,
kExprI64Ctz,
kExprI64Ctz,
kExprI64Shl,
kExprI64Const, 0x41,
kExprI64Ctz,
kExprI64Ctz,
kExprI64Shl,
kExprF32SConvertI64,
kExprUnreachable,
kExprEnd, // @20
])
.exportFunc();
var module = builder.instantiate();
module.exports.test(1, 2, 3);
})();
Original issue's description:
> [turbofan] Correct regalloc blocked register behavior
>
>
> This corrects the case when we need to allocate a
> blocked register, but the blockage happens after a
> use as an instruction input, and there's no place to
> split before that.
>
> BUG=v8:5888
>
> Review-Url: https://codereview.chromium.org/2652153005
> Cr-Commit-Position: refs/heads/master@{#42706}
> Committed: ca779b29a6TBR=bmeurer@chromium.org,jarin@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5888
Review-Url: https://codereview.chromium.org/2654993007
Cr-Commit-Position: refs/heads/master@{#42707}
This corrects the case when we need to allocate a
blocked register, but the blockage happens after a
use as an instruction input, and there's no place to
split before that.
BUG=v8:5888
Review-Url: https://codereview.chromium.org/2652153005
Cr-Commit-Position: refs/heads/master@{#42706}
Port d287c81969
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.
R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=680637
LOG=N
Review-Url: https://codereview.chromium.org/2658053002
Cr-Commit-Position: refs/heads/master@{#42705}
The mentioned asserts did not work properly with interpreted and turbofanned functions.
To fix this issue %GetOptimizationStatus() now returns a set of flags instead of a single value.
This CL also adds more helper functions to mjsunit, like isNeverOptimize(), isAlwaysOptimize(),
isOptimized(fun), etc.
BUG=v8:5890
Review-Url: https://codereview.chromium.org/2654733004
Cr-Commit-Position: refs/heads/master@{#42703}
When testing turning --verify-csa off to generate better code for builtins, mips
started failing mksnapshot due to an assert in instruction-selection-mips.cc's
VisitBinop routine, which creates a buffer to hold InstructionOperand of size 4
that would be overflowed. This fix is somewhat speculative, assuming that either
the LHS or the RHS operand of a mips binary op can be an immediate (as opposed
to the current code which seems to have a code path where both the left and
right operands are added, leading to the buffer overflow). With this fix, the
assert doesn't fire and all of the mips tests run through successfully in debug
mode.
R=ishell@chromium.orgTBR=dusan.m.milosavljevic@gmail.com
Review-Url: https://codereview.chromium.org/2647283009
Cr-Commit-Position: refs/heads/master@{#42701}
The instance type of an object cannot change, only the concrete map
might. So when searching for an instance type witness, we don't need
to pay attention to potentially side-effecting nodes.
R=mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2652893011
Cr-Commit-Position: refs/heads/master@{#42699}
This makes sure that static guarantees about object maps are not used
accross operations on the effect chain that might trigger a map change.
Such operations are missing the {Operator::kNoWrite} property.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-685506
BUG=chromium:685506
Review-Url: https://codereview.chromium.org/2653273004
Cr-Commit-Position: refs/heads/master@{#42697}
According to the WebAssembly spec no arithmetic operation should ever
return a signalling NaN. With the constant folding in V8, however, it
was possible that some arithmetic operations were elided, and if the
input of the arithmetic operation was a signalling NaN, then also the
result was the same signalling NaN. This CL removes some constant
folding optimizations and adjusts others so that even with constant
folding the result of an arithmetic operation is never a signalling NaN.
R=titzer@chromium.org, rossberg@chromium.org, bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2647353007
Cr-Commit-Position: refs/heads/master@{#42694}
We compare ES5, ES6 and a Babel transpilation of the ES6 test.
BUG=v8:5894
Review-Url: https://codereview.chromium.org/2655063003
Cr-Commit-Position: refs/heads/master@{#42689}
The reference map was only recorded when a frame was entered for the
runtime call, but it is also needed when the frame already exists.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2655243002
Cr-Commit-Position: refs/heads/master@{#42687}
- Declaring a variable called "this" for preparsed functions was unnecessary;
DeclarationScope ctor already adds the variable.
- "arguments" for preparsed scopes need to be declared after parsing the
function, like it's done in the parser.
- Now arguments_ can be the dummy variable, so adapted code to it.
- A previous refactoring CL ( https://codereview.chromium.org/2638333002 ) was
incomplete; it had added ParserBase::ParseFunctionBody but
PreParser::ParseFunction didn't call it. This CL completes that work. This is
needed for getting "arguments" declared properly for preparsed functions.
- AllocateVariablesRecursively is already called for preparsed scopes (without
this CL, that is), and it bails out early. However, before the bailout it used
to dcheck num_stack_slots_ == 0; that is no longer true since we've done scope
analysis for preparsed scopes.
- Test fix: we cannot have any lazy inner functions in the test, except the
topmost lazy inner function. Such functions would also be lazy in the parser
case, and the parser would just throw away their variables. Then the test
tries to verify the preparsed data against the scopes without variables and fails.
- Disabled a test w/ a sloppy block function, will get that working again in the
upcoming CLs.
BUG=v8:5516
Review-Url: https://codereview.chromium.org/2655623005
Cr-Commit-Position: refs/heads/master@{#42685}
The InterpreterTester class cobbles together a JSFunction from
a manually created bytecode and feedback vector. However it's
fragile against design changes in the way literal arrays and
feedback vectors are handled. It's better to let it hand in
a feedback vector metadata object, and allow the system to
create the vector from that.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2652893010
Cr-Commit-Position: refs/heads/master@{#42684}
With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained.
At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback:
foo2 (test.js:14:2)
-- Promise.resolve (test.js:29:14)--
-- Promise.resolve (test.js:28:14)--
promiseThen (test.js:30:2)
More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE
BUG=v8:5738
R=dgozman@chromium.org,gsathya@chromium.org
Review-Url: https://codereview.chromium.org/2648873002
Cr-Commit-Position: refs/heads/master@{#42682}
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}
