Problem description:
For prefixed WASM opcode, opcode prefix is printed as Unknown, not the opcode itself.
Take v128.load as an example:
before fix -> after fix
Unknown, 0x00, 0x04, 0x00, -> kExprS128LoadMem, 0x04, 0x00,
Change-Id: Id0cc5c723d19f60ad4f4f6c6ca338b5658c98c7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1694613
Commit-Queue: Jie Pan <jie.pan@intel.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62697}
This reverts commit 13a04abacd.
Reason for revert: Breaks v8 roll (https://chromium-review.googlesource.com/c/chromium/src/+/1698024)
Original change's description:
> fix: move V8_EXPORT_PRIVATE marks to prevent unresolvable references
>
> This change fixes missing symbol errors in the Windows 10 on ARM build
> of Node.js.
>
> When a whole class is marked for export, all of its members are marked
> as well. This can be a problem when inline members call undefined yet
> inline members of other classes: the exported function will contain a
> reference to the undefined inline function that should be satisfied at
> link time, but because the other function is inline no symbol will be
> produced that will satisfy that reference.
>
> Clang gets around this by masking inlined class members from export
> using /Fc:dllexportInlines-. This is why b0a2a567 worked.
>
> Node.js' Windows builds use MSVC and so do not have access to this
> flag. This results in unresolved symbols at link time.
>
> Bug: v8:9465
> Change-Id: Ief9c7ab6ba35d22f995939eb62a64d6f1992ed85
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1696771
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62660}
TBR=sigurds@chromium.org,jgruber@chromium.org,ishell@chromium.org,jkunkee@microsoft.com
Change-Id: Ief2ccb35fc19b00975e78a63791a558525d49ee9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9465
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700069
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62694}
...from the Store constructor/destructor. They were preventing embedders
from using several Stores with overlapping but non-nested lifetimes.
Without Isolate::Enter, such use cases are supported; the only consequence
is that Isolate::Current will not work and therefore must not be called;
but it is deprecated and not called from the Wasm C API anyway.
Change-Id: I65eda00243126e189febb0fd8b38a953c4ee078f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698387
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62692}
The code to create wrapper modules on the fly was dead already.
The code to read wire bytes has been replaced with accesses to
V8's internal decoded form of the same data.
Change-Id: I736c8467df3ded9de08f2d567dbfd5e695dcfb0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698384
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62691}
Move to stage for
harmony_intl_dateformat_day_period
harmony_intl_dateformat_fractional_second_digits
after ECMA402 SC reach consensus July 11 2019 to treat them as Stage 3.
Aiming to flip to ship for m78. Just get ready before sending out I2S
after m77 branch off in end of July.
Bug: v8:9283, v8:9284
Change-Id: I9bb145827157af9debc75cc4fc3859a60a5a023c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699301
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62689}
This CL adds a speculative operator for BigInt negation that is
lowered to the respective builtin call and is optimized to native
64 bit machine operations if truncated. In particular, this change
allows negative BigInt constants (e.g. -5n) to be lowered.
Bug: v8:9407
Change-Id: Ia98fd6dee18a31ce56efbe537f4352b1582539e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695463
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62684}
The code generated for ChangeUint64ToBigInt in the
EffectControlLinearizer did not initialize the optional padding
field of newly allocated BigInts. This padding field is present
on 64 bit builds without pointer compression enabled. This CL
fixes this by 0-filling the padding field if present.
Bug: v8:9407
Change-Id: I511e163e676dc966a3eb6dfb92b5065e36329225
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695464
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Cr-Commit-Position: refs/heads/master@{#62683}
The bytecode graph builder currently creates the tagged template if
it hasn't yet been done. This CL moves that work to serialization time.
Bug: v8:7790
Change-Id: I9571c5ad2f553584869056fb0cf501e03563d6f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687670
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62681}
Similar to https://chromium-review.googlesource.com/c/v8/v8/+/1697246 but
for the Pointer case.
The three CLs combined bring good improvements to the code generation,
both in code size and then in runtime.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: I0903df55f3e19d3ee4dddb3c069ddc27b3265cd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698395
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62678}
Similar to https://chromium-review.googlesource.com/c/v8/v8/+/1697246 but
for the Any case.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: I99f839faad17da35adac8a084289b1553530d4a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698394
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62677}
In essence, it simplifies the pattern (in x64):
movl register, ___
movlsxlq register, register
into:
movlsxlq register, ___
This makes the code smaller and run faster, without compromising.
We can do something similar for Arm64 too.
The cases for Pointer and Any seem to be trickier but there seems to be
room to improve as well.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: I583bdfafdae9330be0a08ad1dd4c196e7de2f0d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697246
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62676}
The serializer clears JSFunctions together with feedback vectors
assuming that there is one to one correspondence between them.
That does not work in the case when there are multiple JSFunctions
sharing the same feedback vector. This patch ensures that all such
JSFunctions are properly cleared.
Bug: v8:7857
Change-Id: Ie441089e12bda5a8be7f9bed90f7be9499938609
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698383
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62673}
Everyone was getting a copy of this through debug.h.
Bug: v8:9396
Change-Id: I5189cb4bf27a3381768b0be479d7b3d60dec20bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695472
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62670}
I noticed the indentation was off in one function, but also fixed
all the other flake8 issues in this file.
Change-Id: I2303ed87da7154484a872315f8355f57621514c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697054
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Sam Clegg <sbc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62669}
Previously, we didn't have access checks for the megamorphic case cause
we'd never get to this IC state for a receiver that doesn't hold the
right private field. But now with lazy feedback allocation we share
the megamorphic case code paths for the uninitialized loads as well,
which exposes our bug.
Bug: chromium:982702
Change-Id: I419406bcfc52575260a85d05520c1662735e15f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697256
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62668}
This CL adds a new FreeList strategy, that can be turned on by using flag
`--gc-freelist-strategy=1`. It is inspired by FreeListLegacy, and differs from
it in the following ways:
- Only has 3 categories: Medium, Large and Huge.
- Any block that would have belong to tiniest, tiny or small in FreeListLegacy
is considered wasted.
- Allocation is done only in Huge, Medium and Large (in that order), using a
first-fit strategy (only the first block of each freelist is ever considered
though).
- Performances is supposed to be better than FreeListLegacy, but memory usage
should be higher (because fragmentation will probably be higher).
Bug: v8:9329
Change-Id: Ib399196788f1dfaa1aeddc3dc721375dd7da65f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697248
Commit-Queue: Darius Mercadier <dmercadier@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62667}
This change implements lowering of speculative BigInt addition as well as
BigInt heap constants to corresponding int64 versions, if they are used in
a context where the result is truncated to the least significant 64 bits
(e.g. using asUintN). The JSHeapBroker is extended to provide access to the
BigInt's least significant digit during concurrent compilation. The BigInt
context (required to introduce correct conversions) is recognized in the
RepresentationChanger by either the output type propagated downward or the
TypeCheckKind propagated upward. This is necessary, because the TypeCheckKind
may only be set by nodes that may potentially deopt (and sit in the effect
chain). This is the case for SpeculativeBigIntAdd, but not for BigIntAsUintN.
This CL contains a simple fix to prevent int64-lowered BigInts to flow into
state values as the deoptimizer cannot handle them yet. A more sophisticated
solution to allow the deoptimizer to materialize truncated BigInts will be
added in a following CL.
Bug: v8:9407
Change-Id: I96a293e9077962f53e5f199857644f004e3ae56e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684183
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62665}
This CL adds the --assert-types flag to d8, which is intended to
insert additional runtime checks after typed nodes, verifying the
validity of our typing rules. So far, only range types are checked.
Thanks to Neil Patil for suggesting something similar.
R=neis@chromium.org, tebbi@chromium.org
Change-Id: I5eb2c482235ec8cd07ee802ca7c12c86c2d3dc40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678372
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62664}
Even though this is not spec'ed yet, it's good to have an implementation
so that we can use clusterfuzz on it.
I changed the parameter order (hopefully) everywhere to
(table_dst_index, table_src_index, ...). This corresponds to the
(dst, src, ...) parameter order for the entry indices.
R=binji@chromium.org
Bug: v8:7581 chromium:980475
Change-Id: I2fb36ffd4bb2f2be5b22c8366732295fa6759236
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698386
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62661}
This change fixes missing symbol errors in the Windows 10 on ARM build
of Node.js.
When a whole class is marked for export, all of its members are marked
as well. This can be a problem when inline members call undefined yet
inline members of other classes: the exported function will contain a
reference to the undefined inline function that should be satisfied at
link time, but because the other function is inline no symbol will be
produced that will satisfy that reference.
Clang gets around this by masking inlined class members from export
using /Fc:dllexportInlines-. This is why b0a2a567 worked.
Node.js' Windows builds use MSVC and so do not have access to this
flag. This results in unresolved symbols at link time.
Bug: v8:9465
Change-Id: Ief9c7ab6ba35d22f995939eb62a64d6f1992ed85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1696771
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62660}
This is a reland of https://crrev.com/c/v8/v8/+/1692366. The original
change was reverted because it broke some blink tests. This will be
landed after suppressing them:
https://crrev.com/c/chromium/src/+/1695541
Make native errors serializable.
The implementation is mostly straightforward, but there is one
exception: the stack property. Although the property is not specified,
the spec for error cloning asks us to preserve the property if
possible. This implementation serializes the property only when it is
a string, and otherwise ignores it.
Spec: https://github.com/whatwg/html/pull/4665
Intent-to-Ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/f8JngIi8qYs
Bug: chromium:970079, v8:9462
Change-Id: Ibf012754f30237f6b5acf119ef834e73727a230f
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695202
Auto-Submit: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62659}
Rolling v8/build: 40634f1..c989268
Rolling v8/buildtools: 80b545b..95c72f3
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b79dda9..1abe66f
Rolling v8/third_party/depot_tools: d3f6994..78dec04
Rolling v8/tools/luci-go: git_revision:25958d48e89e980e2a97daeddc977fb5e2e1fb8c..git_revision:7d11fd9e66407c49cb6c8546a2ae45ea993a240c
Rolling v8/tools/luci-go: git_revision:25958d48e89e980e2a97daeddc977fb5e2e1fb8c..git_revision:7d11fd9e66407c49cb6c8546a2ae45ea993a240c
Rolling v8/tools/luci-go: git_revision:25958d48e89e980e2a97daeddc977fb5e2e1fb8c..git_revision:7d11fd9e66407c49cb6c8546a2ae45ea993a240c
TBR=machenbach@chromium.org,sergiyb@chromium.org,tmrts@chromium.org
Change-Id: I014010e41a1fe31582ab5aa3abbb28b1f1be32f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698803
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#62658}
The alignment should be 3 (i.e. 8 bytes), but was specified as 2 (i.e. 4
bytes).
Bug: v8:9425
Change-Id: I0beb09df25fe0281ed604909e894afd804f5411e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1693836
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62657}
Even though this is not spec'ed yet, it's good to have an implementation
so that we can use clusterfuzz on it.
R=binji@chromium.org
Bug: v8:7581
Change-Id: I323625322e5240dc6ac224dce8a1f1f7f6070758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695478
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62656}
With lazy feedback allocation and bytecode flushing we need to call
%PrepareFunctionForOptimize before we call %OptimizeFunctionOnNextCall/
%OptimizeOsr. This cl:
1. Adds an additional state in pending optimized table to check if the
optimization was triggered manually.
2. Changes the compilation pipeline to delete the entry from pending
optimized table only if the optimization was triggered through
%OptimizeFunctionOnNextCall / %OptimizeOsr.
3. Adds a check to enforce %PrepareFunctionForOptimize was called.
4. Adds a new run-time flag to only check in the d8 test runner. We
don't want this check enabled in other cases like clusterfuzz that doesn't
ensure %PrepareFunctionForOptimize is called.
Bug: v8:8394, v8:8801, v8:9183
Change-Id: I9ae2b2da812e313c746b6df0b2da864c2ed5de51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664810
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62653}
BasicMemoryChunk sits above the MemoryChunk in the chunk hierarchy and
is responsible for storing the bare minimum data to identify a chunk of
memory, without worrying about GC etc.
This change also completes the MemoryChunk offset asserts, which were
previously missing for few key properties.
Bug: v8:7464
Change-Id: Id4c7716c4ed5722ceca3cbc66d668aed016c74b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688843
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62652}
The simulator builds have bugs which cause invalid frame markers in
some cases.
Change-Id: I837732c6f5efe24821415a0ae0626578bbcc3a7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697253
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62650}
GetOwnPropertyNameTryFast uses ENUMERABLE_STRINGS filter to trigger fast
path in KeyAccumulator::GetKeys conditionally when all properties on the
receiver are enumerable. It is not easy to verify if all properties are
enumerable and the current check is incorrect in some cases.
For ex: when we have non-enumerable properties when we have elements on
the receiver. This cl removes this try_fast path from the builtin. This
could impact performance. The long term fix for this would be to fix
KeyAccumulator::GetKeys to use fast path for more cases.
Bug: chromium:977870
Change-Id: Iecde730739c2c452ffa0d893d0d1b3612a45d1b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679499
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62649}
