This fixes the case where a module is instantiated twice via the same
closure when in the meantime another closure has destroyed and removed
the WASM data attached to the SharedFunctionInfo.
R=bradnelson@chromium.org
TEST=mjsunit/asm/asm-validation
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2253613004
Cr-Commit-Position: refs/heads/master@{#38696}
Rolling v8/build to 388e658306466650ee4ad4b3d6d7b230c9cad64c
Rolling v8/third_party/icu to 2341038bf72869a5683a893a2b319a48ffec7f62
Rolling v8/tools/mb to f3036b2e34d746db3635afa0841f51019b2b8d38
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2259703002
Cr-Commit-Position: refs/heads/master@{#38695}
Language tags with Unicode extensions can have multiple subtags
for a key (e.g. -ca-ismalic-civil has 'islamic-civi' for 'ca').
BUG=v8:4749
TEST=intl/date-format/calendar-with-multiple-type-subtags.js
Review-Url: https://codereview.chromium.org/2248563003
Cr-Commit-Position: refs/heads/master@{#38692}
Reason for revert:
WebGL tests have been updated and rolled (at https://codereview.chromium.org/2227023002), so this should no longer fail outdated tests.
Original issue's description:
> Revert of Amend DataView, ArrayBuffer, and TypedArray methods to use ToIndex. (patchset #8 id:140001 of https://codereview.chromium.org/2090353003/ )
>
> Reason for revert:
> Speculative revert to unblock roll: https://codereview.chromium.org/2107223003/
>
> Original issue's description:
> > Amend DataView, ArrayBuffer, and TypedArray methods to use ToIndex.
> >
> > The spec was modified to relax some requirements which implementors had not been
> > enforcing. Part of this process involved introducing a new abstract operation
> > ToIndex, which had partial overlap with our existing semantics as well as some
> > differences (most notably treating undefined as 0). Test262 tests were introduced to
> > check for the new semantics, some of which we were failing. This patch amends the
> > parts of our implementation corresponding to specification algorithms which use
> > ToIndex to follow its semantics precisely.
> >
> > BUG=v8:4784,v8:5120
> >
> > Committed: https://crrev.com/09720349ea058d178521ec58d0a5676443a5a132
> > Cr-Commit-Position: refs/heads/master@{#37406}
>
> TBR=littledan@chromium.org,adamk@chromium.org,bakkot@google.com
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4784,v8:5120
>
> Committed: https://crrev.com/b1f7f1f4e41a723d5f997738a07e35a031713b8f
> Cr-Commit-Position: refs/heads/master@{#37417}
TBR=littledan@chromium.org,adamk@chromium.org,hablich@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:4784,v8:5120
Review-Url: https://codereview.chromium.org/2247073004
Cr-Commit-Position: refs/heads/master@{#38689}
Our previous per-arch instantiation thunks for asm.js
didn't support modules that had or were called with anything other
than 3 arguments. Adding support for this.
Addding a runtime test method to check if asm validation succeeded.
Adding a test of validation with different argument count combinations.
R=mstarzinger@chromium.org
TEST=mjsunit/asm/asm-validator.js
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
Review-Url: https://codereview.chromium.org/2229723002
Cr-Commit-Position: refs/heads/master@{#38688}
The "version 0" format did not deal with references, and used a stack model to
deserialize objects (conceptually, a postorder tree traversal). This requires
an explicit stack, so special logic is added to decode this format.
All subsequent versions also put an object marker at the beginning, which is
equivalent to how the current version serializes.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2248893003
Cr-Commit-Position: refs/heads/master@{#38686}
Async functions are implemented via special generator functions; special in the
sense that they generally do not immediately yield. However, our generators
implementation still assumed that every generator function initially yields
(concretely: before doing the state dispatch in a loop header). This CL fixes
that.
R=littledan@chromium.org, rmcilroy@chromium.org
BUG=chromium:638019
Review-Url: https://codereview.chromium.org/2253033002
Cr-Commit-Position: refs/heads/master@{#38684}
As part of this CL, object reference tracking is implemented (and tested with a
self-referential object). This sort of reference tracking will be shared with
other receivers (array, date, regexp and host objects).
Not included in this CL is compatibility with version-0 objects (which don't
support a non-tree object graph, and require a little stack to correctly
deserialize).
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2246093003
Cr-Commit-Position: refs/heads/master@{#38683}
The Smi case was updating the feedback with a bitwise AND instead of a bitwise OR. This was causing feedback that should have been 'kAny' to be erroneusly reported as 'kSignedSmall'.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2251863004
Cr-Commit-Position: refs/heads/master@{#38682}
We mark an object allocated as uninitialized. If we happen to have a GC before
fields of a map are written, msan will observe access to unitialized memory and
crash.
This also unifies the handling as we now deal with all spaces in the same way.
In future we could parallelize clearing.
BUG=chromium:638226
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2251993002
Cr-Commit-Position: refs/heads/master@{#38681}
Fix 2cf2eef77b
Fix test failures with tests working on external Uint32 arrays. Problem
started to appear because Uint32 value was compared using Int32 compare
operators in ChangeUint32ToTagged. On MIPS64. Uint32 value is not sign-
extended, so upper 32 bits of this value are zero. MIPS64 doesn't have
Word32Compare instructions but uses Word64Compare instructions in
combination with properly sign-extended Int32 values.
BUG=cctest/test-api/Uint32Array,cctest/test-api/SharedUint32Array,
cctest/test-api/FixedUint32Array,mjsunit/compiler/uint32
Review-Url: https://codereview.chromium.org/2231053002
Cr-Commit-Position: refs/heads/master@{#38680}
This removes the representation axis from the type of {Load/StoreField}
operators representing a property load/store. The representation would
be narrowed to {None} which causes problems for all places where we use
the type to reason about the value representation. Instead we should
fully switch to {MachineRepresentation}. This is just a stop-gap fix.
R=jarin@chromium.org
BUG=chromium:636716
Review-Url: https://codereview.chromium.org/2255533003
Cr-Commit-Position: refs/heads/master@{#38678}
1, restrict use of LiteralBuffers to the tokens that actually need it.
- E.g., previously the Token::FUNCTION would have a literal buffer
containing "function", which was never actually used.
- This eliminates copies of the string data for every call to
PeekAhead or SetBookmark.
2, document & enforce the "secret" Scanner API contract w/ DCHECK
- Document & check the correspondence of token value and literal buffer.
- Document & check preconditions for calling PeekAhead, ScanRegExp*,
ScanTemplate*.
BUG=v8:4947
Review-Url: https://codereview.chromium.org/2240513003
Cr-Commit-Position: refs/heads/master@{#38677}
Now that all backends use the source position builder to record source
positions, simplify the code line logging events to take a source
position table on code creation. This means that the source position
table builder no longer needs to access the isolate until the table is
generated. This is required for off-thread bytecode generation.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2248673002
Cr-Commit-Position: refs/heads/master@{#38676}
At the moment, two NumberConstant nodes get different type even if their
value is the same because we always allocate a new heap number for
each number constant. This can lead to replacing a node with a node of
disjoint type in value numbering, which can result in incorrect code
down the line because of inconsistent types.
This fix makes sure that we only replace a node with a sub-type
node. Once we introduce a proper type for number constants, we can
move back to the intersection typing in value numbering.
Unfortunately, it is quite hard to write a repro for this because we cache NumberConstant nodes. We only throw away cached values that have too many conflicts (>5), so the test has to contain values that fall into the same bucket. That's where the magic floating point numbers in the test come from (they have the same low 8-bits of their hashes).
BUG=chromium:633497
Review-Url: https://codereview.chromium.org/2251833002
Cr-Commit-Position: refs/heads/master@{#38675}
This CL removes the optional operator flag of Float64Max and Float64Min.
Additionally it renames the instruction codes on x64 and ia32 because
the old instructions codes (e.g. SSEFloat64Max) do not match the
generated code anymore.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2237813002
Cr-Commit-Position: refs/heads/master@{#38674}
Rolling v8/build to 9a1647ec813695da7960692f711a1cebc948d551
Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to b53e3af6bfca3333fc2dd69302dac6667a8c6418
Rolling v8/tools/clang to b5889296bac50b31f1d2806633fe99dfc2b26b54
Rolling v8/tools/mb to c5a112880d83d509e88c01d524c988845a3a3ba6
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2247183004
Cr-Commit-Position: refs/heads/master@{#38672}
Reason for revert:
Breaks Win64 bot
Original issue's description:
> [Interpreter] Introduce InterpreterCompilationJob
>
> Adds InterpreterCompilationJob as a sub-class of
> CompilationJob, to enable off-thread bytecode
> generation. Currently only used in
> Interpreter::MakeBytecode.
>
> As part of this change, CompilationJob is modified
> to make it less specific to optimized compilation,
> renaming the phases as follows:
> - CreateGraph -> PrepareJob
> - OptimizeGraph -> ExecuteJob
> - GenerateCode -> FinalizeJob
>
> RegisterWeakObjectsInOptimizedCode is also moved out
> of CompilationJob and instead becomes a static function
> on Compiler.
>
> BUG=v8:5203
>
> Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
> Committed: https://crrev.com/785990e9fc0dd9a9d963d25d0bed2909165e4ca9
> Cr-Original-Commit-Position: refs/heads/master@{#38662}
> Cr-Commit-Position: refs/heads/master@{#38668}
TBR=mstarzinger@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2251673003
Cr-Commit-Position: refs/heads/master@{#38669}
Adds InterpreterCompilationJob as a sub-class of
CompilationJob, to enable off-thread bytecode
generation. Currently only used in
Interpreter::MakeBytecode.
As part of this change, CompilationJob is modified
to make it less specific to optimized compilation,
renaming the phases as follows:
- CreateGraph -> PrepareJob
- OptimizeGraph -> ExecuteJob
- GenerateCode -> FinalizeJob
RegisterWeakObjectsInOptimizedCode is also moved out
of CompilationJob and instead becomes a static function
on Compiler.
BUG=v8:5203
Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
Review-Url: https://codereview.chromium.org/2240463002
Cr-Original-Commit-Position: refs/heads/master@{#38662}
Cr-Commit-Position: refs/heads/master@{#38668}
If a key is a substring of an earlier value, then the earlier value
will unintentionally be clobbered. For example with:
macro SET_PRIVATE(obj, sym, val) = (obj[sym] = val);
SET_PRIVATE(iterator, arrayIteratorObjectSymbol, object);
if the mapping is:
{'val': 'object',
'obj': 'iterator',
'sym': 'arrayIteratorObjectSymbol'}
then 'obj' -> 'iterator' will clobber 'val' -> 'object', resulting in
'val' -> 'iteratorect'. To fix this, replace all substitutions
simultaneously.
Patch from Zoe Clifford <zoeclifford@google.com>
Review-Url: https://codereview.chromium.org/2249873004
Cr-Commit-Position: refs/heads/master@{#38665}
Reason for revert:
Failing on Win64 bot:
https://build.chromium.org/p/client.v8/builders/V8%20Win64/builds/12061/steps/Check/logs/regress-635429
Original issue's description:
> [Interpreter] Introduce InterpreterCompilationJob
>
> Adds InterpreterCompilationJob as a sub-class of
> CompilationJob, to enable off-thread bytecode
> generation. Currently only used in
> Interpreter::MakeBytecode.
>
> As part of this change, CompilationJob is modified
> to make it less specific to optimized compilation,
> renaming the phases as follows:
> - CreateGraph -> PrepareJob
> - OptimizeGraph -> ExecuteJob
> - GenerateCode -> FinalizeJob
>
> RegisterWeakObjectsInOptimizedCode is also moved out
> of CompilationJob and instead becomes a static function
> on Compiler.
>
> BUG=v8:5203
>
> Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
> Cr-Commit-Position: refs/heads/master@{#38662}
TBR=mstarzinger@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2249153002
Cr-Commit-Position: refs/heads/master@{#38663}
Adds InterpreterCompilationJob as a sub-class of
CompilationJob, to enable off-thread bytecode
generation. Currently only used in
Interpreter::MakeBytecode.
As part of this change, CompilationJob is modified
to make it less specific to optimized compilation,
renaming the phases as follows:
- CreateGraph -> PrepareJob
- OptimizeGraph -> ExecuteJob
- GenerateCode -> FinalizeJob
RegisterWeakObjectsInOptimizedCode is also moved out
of CompilationJob and instead becomes a static function
on Compiler.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2240463002
Cr-Commit-Position: refs/heads/master@{#38662}
Port 77c9cb8341.
Original commit message:
This commit fixes wasm little-endian load issue on big-endian platform
by introducing reverse byte operation immediately after a load.
BUG=
Review-Url: https://codereview.chromium.org/2235703002
Cr-Commit-Position: refs/heads/master@{#38660}
There was a weird check in AllocateNonParameterLocal which looked
like ".result" was treated differently from other
temporaries. This couldn't be generalized to other temporaries,
since some temporaries were both in temps_ and params_ (and some,
like ".result" would be only in params_).
Side product: Don't use AstValueFactory in scope analysis. It's
unnecessary (was only used for some DCHECKs which can be replaced
with more general checks). This change also ensures we don't
create new values during scope analysis.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2242783002
Cr-Commit-Position: refs/heads/master@{#38655}
Port d61a5c376b
Original commit message:
As a first step I uncommit the memory on the main thread. Also
to measure impact and stability of that optimization. In a
follow-up CL, the uncommitting should be moved on the concurrent thread.
R=jochen@chromium.org, hpayer@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2245703002
Cr-Commit-Position: refs/heads/master@{#38654}
Slots in ConsString/SlicedString can point to an evacutaion candidate.
The MakeExternal function makes in-place conversion to external string.
After the conversion we can have a recorded slot containing an external
pointer. As long as the external pointer is aligned, this is not a
problem. We clear the recorded slots to fix verify-heap checks.
BUG=chromium:631969
LOG=NO
Finalizing CL: https://codereview.chromium.org/2199863002/
Review-Url: https://codereview.chromium.org/2242183003
Cr-Commit-Position: refs/heads/master@{#38653}
Allows us to create a corresponding TurboFan node, so TF can
optimize it.
BUG=v8:4280
LOG=n
Review-Url: https://codereview.chromium.org/2248633002
Cr-Commit-Position: refs/heads/master@{#38651}
This moves language-mode initialization for MODULE_SCOPE from Scope::SetDefaults to the single constructor that needs to do it. The CL additionally makes it more obvious that scope-info-backed scopes always initialize language-mode unless WITH_SCOPE.
BUG=
Review-Url: https://codereview.chromium.org/2251683002
Cr-Commit-Position: refs/heads/master@{#38650}
This stages the --ignition-preserve-bytecode flag which preserves the
bytecode even when switching to baseline code. It is now implied by the
combined --ignition-staging flag.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2244303003
Cr-Commit-Position: refs/heads/master@{#38648}
