Reason for revert:
Seems to break layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/13146https://github.com/v8/v8/wiki/Blink-layout-tests
Original issue's description:
> ValueSerializer: Distinguish between 'undefined' and an absent property.
>
> Dealing with this case requires a wire format change. It is possible that an
> element can be absent even in an array where the dense format was chosen
> (because the array initially had no holes), if the elements are modified while
> they are being serialized. In this case, a new tag for the "hole" is emitted.
>
> The logic to treat undefined in dense arrays as an absent property is restricted
> to versions of the wire format that this tag did not exist.
>
> BUG=chromium:686159,chromium:665820
>
> Review-Url: https://codereview.chromium.org/2660093002
> Cr-Commit-Position: refs/heads/master@{#42784}
> Committed: dc85f4c833TBR=jkummerow@chromium.org,jbroman@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:686159,chromium:665820
Review-Url: https://codereview.chromium.org/2667553003
Cr-Commit-Position: refs/heads/master@{#42788}
Dealing with this case requires a wire format change. It is possible that an
element can be absent even in an array where the dense format was chosen
(because the array initially had no holes), if the elements are modified while
they are being serialized. In this case, a new tag for the "hole" is emitted.
The logic to treat undefined in dense arrays as an absent property is restricted
to versions of the wire format that this tag did not exist.
BUG=chromium:686159,chromium:665820
Review-Url: https://codereview.chromium.org/2660093002
Cr-Commit-Position: refs/heads/master@{#42784}
When WebAssembly.Table initial size is greater than the declared initial size, table size references should be updated on instantiate for functions to be called at indices greater than the declared initial size.
R=bradnelson@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2661773002
Cr-Commit-Position: refs/heads/master@{#42781}
Without this CL we have only limit for amount of console messages and if user are dumping a huge messages we pretty soon run out of memory.
So let's introduce limit for memory consumption it would help chromium and Node.js as well.
BUG=chromium:671489
R=dgozman@chomium.org,alph@chromium.org, hpayer@chromium.org, ulan@chromium.org
Review-Url: https://codereview.chromium.org/2653293003
Cr-Commit-Position: refs/heads/master@{#42780}
The graphs don't show any performance bump for
https://codereview.chromium.org/2659623002, which I do see a much better result for
locally. I suspect the function isn't being optimized in turbofan when the
benchmarks run. Maybe this warmup flag will trigger that.
BUG=v8:5895
Review-Url: https://codereview.chromium.org/2664783002
Cr-Commit-Position: refs/heads/master@{#42776}
They have the same lifetime. It's a match!
Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.
A follow-on CL removes even more parser infrastructure related to this count.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
Where the arguments have already been inlined, we can replace these calls with a
direct call to construct. We have to make sure that the iteration over the arguments is not observable.
BUG=v8:5895
Review-Url: https://codereview.chromium.org/2659623002
Cr-Commit-Position: refs/heads/master@{#42765}
This avoids using kTaggedSigned and kTaggedPointer because the
semantic information of those type could be invalid in unreachable
code.
For example, SmiCheck(0.1) has representation TaggedSigned, but it is
later compiled to DeoptimizeUnless(ObjectIsSmi(0.1)) with the constant
0.1 directly connected to the uses. If the use is state-values, which
recorded the TaggedSigned representation of CheckSmi, the code
generator will be confused because it will see constant 0.1 that
claims to be TaggedSigned value.
BUG=chromium:675704
Review-Url: https://codereview.chromium.org/2656243004
Cr-Commit-Position: refs/heads/master@{#42756}
memcpy is faster than UTF-8 encoding/decoding. This yields 10-20% wins on
serializing and deserializing long ASCII strings, according to
blink_perf.bindings -- and these are already in a fast path where the entire
string is known to be ASCII (but this has to be checked). The win may be
larger for strings in Latin-1 but not ASCII (though I suspect this is an
uncommon case).
A change is also made to make ValueSerializerTest.EncodeTwoByteStringUsesPadding
survive wire format version number changes.
This is the first of a series of wire format changes from the previous Blink
format. The deserializer continues to be able to read the old format, but
Chromium M56 will no longer be able to read the messages written by this, in M58.
BUG=chromium:686159
Review-Url: https://codereview.chromium.org/2658793004
Cr-Commit-Position: refs/heads/master@{#42753}
This unifies the behavior of Scope::DeclareVariableName with
Scope::DeclareVariable.
BUG=v8:5516
Review-Url: https://codereview.chromium.org/2658063005
Cr-Commit-Position: refs/heads/master@{#42744}
Some tests require a lot of memory and they fail on buildbots if they run
in parallel with other tests of the same kind.
We try to limit this by disabling multiple vairants of the same tests,
assuming this would stop the failures in most of the cases.
BUG=
Review-Url: https://codereview.chromium.org/2653603002
Cr-Commit-Position: refs/heads/master@{#42741}
The StringIndexOf operation is pure on the JS level, but the actual stub
call must be in the effect chain later so that the Scheduler doesn't
place it inside some allocation region (The %StringIndexOf runtime
function may trigger a GC for string flattening).
BUG=chromium:685580
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2657243002
Cr-Commit-Position: refs/heads/master@{#42736}
Basically, with --deopt-every-n-times flag all bets are off since
the functions can be optimized and deoptimized at any time.
BUG=v8:5890
Review-Url: https://codereview.chromium.org/2655263004
Cr-Commit-Position: refs/heads/master@{#42735}
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-Original-Commit-Position: refs/heads/master@{#42703}
Committed: d1ddec7857
Review-Url: https://codereview.chromium.org/2654733004
Cr-Commit-Position: refs/heads/master@{#42731}
Always execute the implicit return if we fell off the function bytes.
This is not considered an additional "step" as it is not executing a
wasm instruction.
Otherwise, we might pause at an invalid position (one after the
function bytes).
R=titzer@chromium.org
BUG=v8:5822
Review-Url: https://codereview.chromium.org/2650293003
Cr-Commit-Position: refs/heads/master@{#42730}
Previously, when restarting a frame, we would rewrite all frames
between the debugger activation and the frame to restart to squash
them, and replace the return address with that of a builtin to
leave that rewritten frame, and restart the function by calling it.
We now simply remember the frame to drop to, and upon returning
from the debugger, we check whether to drop the frame, load the
new FP, and restart the function.
R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5587
Review-Url: https://codereview.chromium.org/2636913002
Cr-Commit-Position: refs/heads/master@{#42725}
Memory.Grow should detach the ArrayBuffer associated with the Mem object after Grow. Currently, when guard pages are enabled protection is changed to make more of the buffer accessible. This does not work for when the buffer should be detached after grow, because the memory object has a reference to the same buffer befor/after grow.
R=titzer@chromium.org, eholk@chromium.org
Review-Url: https://codereview.chromium.org/2653183003
Cr-Commit-Position: refs/heads/master@{#42717}
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}
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}
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}
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}
