Bug=v8:8075
R=adamk@chromium.org,binji@chromium.org
Change-Id: I11ef5daccd043123b23e60c93ee0df79cabe9ccd
Reviewed-on: https://chromium-review.googlesource.com/c/1342948
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57917}
This constant is unused, and should never be used, since name sections
are encoded as an unknown section with the special name "name".
R=ahaas@chromium.org
Change-Id: I2fa1a21506dbe30033aecb3c1bf9ad84b6b872bc
Reviewed-on: https://chromium-review.googlesource.com/c/1352305
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57905}
This avoids leaving the heap in an invalid state if a GC occurs during
population of the cloned property array, as is done in other IC
builtins.
BUG=chromium:904167, v8:7611
R=jkummerow@chromium.org, ishell@chromium.org
Change-Id: I0350ed2d65b72e299f7109b7d5aa86331f60e940
Reviewed-on: https://chromium-review.googlesource.com/c/1350282
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57879}
The {setTableLength} method is redundant and has a single user. Remove
it, use {setTableBounds} instead.
Drive-by: Add default to the table max, to document that this can
actually be {undefined}, in which case the table has no maximum.
R=binji@chromium.org
Bug: v8:8238
Change-Id: I0d7a2f4d49d083f7adadbb4b6cd4933bcb1dc174
Reviewed-on: https://chromium-review.googlesource.com/c/1350126
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57860}
This CL adds new Wasm import call kinds that correspond to various
math functions that can be imported from JavaScript, such as trigonometry.
Instead of calling a special import wrapper that converts arguments
to tagged values by boxing, we can now generate calls to little WASM
stubs that contain a single WASM bytecode each.
R=mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I59b1be2dd36d190a8b6c98b88c86cecc0ca7f4a2
Reviewed-on: https://chromium-review.googlesource.com/c/1349279
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57835}
We cannot assign a meaningful type to Promise#catch() or
Promise#finally(), since they both return whatever the invocation of
'then' on the receiver returns, and that is monkeypatchable by arbitrary
user JavaScript.
Bug: chromium:908309, v8:7253
Change-Id: Ib15f81c366938a1b1f10be6c6af85c1f3374b898
Reviewed-on: https://chromium-review.googlesource.com/c/1350789
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57828}
This is a reland of a5336471f2
Original change's description:
> [builtins] Implement Object.fromEntries
>
> Adds the Object.fromEntries() method behind
> --harmony-object-from-entries.
>
> > Includes an initial implementation of the new experimental builtin
> Object.fromEntries implemented by Daniel Clifford, and
> has been modified by Caitlin Potter to support a fast case to skip
> the iterator protocol when it can be done unobservably in common cases.
>
> There are some incidental changes: A number of CSA macros have been
> updated to use TNodes, and some Context arguments have been
> re-arranged to be implicit in Torque. >
>
> There are also a number of mjsunit tests written mirroring and
> expanding on the test262 tests.
>
> BUG=v8:8021
>
> Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
> Co-authored-by: Daniel Clifford <danno@chromium.org>
> Co-authored-by: Caitlin Potter <caitp@igalia.com>
> Reviewed-on: https://chromium-review.googlesource.com/c/1337585
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57667}
Bug: v8:8021
Change-Id: I706e2d87bfc2f688e833c1b7d40ca82f5d80f5a2
Reviewed-on: https://chromium-review.googlesource.com/c/1346630
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57798}
Rather check expressions used as patterns directly. Check parentheses by
tagging parenthesized expressions as parenthesized.
This allows us to drop UnexpectedPatternToken and makes it clear why a specific
token is unexpected (because it's invalid in a binding pattern).
This also more uniformly restores messages like "Invalid destructuring
assignment target".
Change-Id: Idd98e9116c85de4c2304cf1fef1baa097b67149d
Reviewed-on: https://chromium-review.googlesource.com/c/1349572
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57792}
Instead, simply track it as a valid binding pattern. To do this in the case of
parenthesized formals, we delay throwing the binding pattern error for
parenthesized (and async "calls") until we know it's not an arrow function head
by itself.
This guarantees that if an arrow head is a valid binding pattern, it's either a
valid parenthesized head or a valid identifier, or invalid pattern ("array" or
"object" literal style). We can detect the latter case by checking that the
current token is not a RPAREN and the expression isn't an identifier.
(Alternatively we could check that the curren token is RBRACE or RBRACK...)
Bug: chromium:907575
Change-Id: Ie40cc3235d3188f2620b6c089a0f49d93604dda6
Reviewed-on: https://chromium-review.googlesource.com/c/1348078
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57743}
Many tests were already skipped in debug mode, but they kept running on CQ
which sets dcheck_always_on, probably equally slow.
Some other tests are marked as slow based on a recent run of the arm64 sim
trybot.
NOTRY=true
Bug: v8:7783
Change-Id: Ic022518edfa112ea6d228ae9a68653c99651dbb4
Reviewed-on: https://chromium-review.googlesource.com/c/1347479
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57724}
This CL moves optimization capabilities from typed lowering to typed
optimization. In particular, this allows retyping of Speculative to
number optimizations depending on their input types. This can save type
checks if we know that inputs are already in SafeIntegerRange and uses
are truncating to 32bit integers.
This change recovers the performance lost to 31bit Smis on
Octane/crypto on x64:
32bit nosmis avg 30,984.84 stddev 180.52
31bit smis (w/o patch) avg 29,438.52 stddev 120.30 -4.99%
31bit smis avg 31,274.52 stddev 176.26 +0.93% +6.24%
Change-Id: I86d6e37305262336f4f7bd46aac0d2cbca11e8c1
Bug: v8:8344
Reviewed-on: https://chromium-review.googlesource.com/c/1323729
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57717}
Moves allocation of the WasmModuleObject for asm.js code out of SyncCompileTranslatedAsmJS
since that is called when we are compiling the native context independent SharedFunctionInfo
and the WasmModuleObject requires a native context. Instead save the members required to
create the object in the AsmWasmData and create it during module instantiation. Note:
since the Wasm module is an implementation detail for asm_wasm code and isn't exposed,
this doeesn't have semantic change for asm.js code.
As part of this change, the AsmWasmData is changed from a FixedArray to a dedicated
struct. Some logic is also moved from module-compiler to wasm-engine to make the
seperation between Wasm SyncCompile and AsmJS SyncCompile more clear.
BUG=chromium:900535,v8:8395
Change-Id: Ia48469c095b0688f210aa86e7430c9ab4ea4b26b
Reviewed-on: https://chromium-review.googlesource.com/c/1345509
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57704}
Load elimination is running together with to dead code elimination, the
latter of which might eliminate allocations (in particular FinishRegion
nodes). These are treated as alias nodes by load elimination, and load
elimination does not immediatelly learn that a node has been disconnected.
This causes load elimination to access the inputs of dead code eliminated
nodes while resolving renames, which causes nullptr dereferences.
This CL modifies load elimination to not resolve to a nullptr alias but
simply stop before that.
Change-Id: If4cef061c7c0e25f353727c9e27f790439b0beb5
Bug: chromium:906406
Reviewed-on: https://chromium-review.googlesource.com/c/1346491
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57688}
This reverts commit a5336471f2.
Reason for revert: Fails nosnap debug tests: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21838
Original change's description:
> [builtins] Implement Object.fromEntries
>
> Adds the Object.fromEntries() method behind
> --harmony-object-from-entries.
>
> > Includes an initial implementation of the new experimental builtin
> Object.fromEntries implemented by Daniel Clifford, and
> has been modified by Caitlin Potter to support a fast case to skip
> the iterator protocol when it can be done unobservably in common cases.
>
> There are some incidental changes: A number of CSA macros have been
> updated to use TNodes, and some Context arguments have been
> re-arranged to be implicit in Torque. >
>
> There are also a number of mjsunit tests written mirroring and
> expanding on the test262 tests.
>
> BUG=v8:8021
>
> Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
> Co-authored-by: Daniel Clifford <danno@chromium.org>
> Co-authored-by: Caitlin Potter <caitp@igalia.com>
> Reviewed-on: https://chromium-review.googlesource.com/c/1337585
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57667}
TBR=danno@chromium.org,caitp@igalia.com,tebbi@chromium.org
Change-Id: Id0cd8b16131f151a42dffbaca7e59ab17c68ab23
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8021
Reviewed-on: https://chromium-review.googlesource.com/c/1346116
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57677}
Adds the Object.fromEntries() method behind
--harmony-object-from-entries.
Includes an initial implementation of the new experimental builtin
Object.fromEntries implemented by Daniel Clifford, and
has been modified by Caitlin Potter to support a fast case to skip
the iterator protocol when it can be done unobservably in common cases.
There are some incidental changes: A number of CSA macros have been
updated to use TNodes, and some Context arguments have been
re-arranged to be implicit in Torque.
There are also a number of mjsunit tests written mirroring and
expanding on the test262 tests.
BUG=v8:8021
Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
Co-authored-by: Daniel Clifford <danno@chromium.org>
Co-authored-by: Caitlin Potter <caitp@igalia.com>
Reviewed-on: https://chromium-review.googlesource.com/c/1337585
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57667}
This is a reland of 585b4eef6a without
any changes.
Original change's description:
> [turbofan] Improve NumberMultiply typing rule.
>
> The NumberMultiply typing rule gave up in the presence of NaN inputs,
> but we can still infer useful ranges here and just union the result
> of that with the NaN propagation (similar for MinusZero propagation).
> This way we can still makes sense of these ranges at the uses.
>
> Bug: v8:8015
> Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92
> Reviewed-on: https://chromium-review.googlesource.com/c/1261143
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56539}
Tbr: bmeurer@chromium.org
Bug: v8:8015
Change-Id: I32e5c2f439a1186891ca3393ee53a2a766585839
Reviewed-on: https://chromium-review.googlesource.com/c/1345993
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57664}
Previously the simplified operation `Number.min(x,y)` would lower to
`Select(Float64LessThan(x, y), x, y)` which would yield `y` when both
`x` and `y` are zeros, specifically when `x` was -0 and `y` was +0.
For `NumberMin` we need to use `Float64LessThanOrEqual` since we
generally allow -0 on the left hand side (in SimplifiedLowering).
Bug: chromium:906870
Change-Id: I25ae8fb19608b77c90ed130e69d9d9fa93fcea9d
Reviewed-on: https://chromium-review.googlesource.com/c/1342920
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57633}
This reverts commit 585b4eef6a.
Reason for revert: Speculative, crbug 906567.
Original change's description:
> [turbofan] Improve NumberMultiply typing rule.
>
> The NumberMultiply typing rule gave up in the presence of NaN inputs,
> but we can still infer useful ranges here and just union the result
> of that with the NaN propagation (similar for MinusZero propagation).
> This way we can still makes sense of these ranges at the uses.
>
> Bug: v8:8015
> Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92
> Reviewed-on: https://chromium-review.googlesource.com/c/1261143
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56539}
TBR=sigurds@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8015
Change-Id: I3c652bafbbc0e5d1ad4ff288264fd4f4cbf71330
Reviewed-on: https://chromium-review.googlesource.com/c/1340253
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57602}
Fail IsInvalid check if the property cell has been invalidated.
Bug: chromium:905555
Change-Id: Ia0712b97bd6ba628936b74b3893ddb1c229ee686
Reviewed-on: https://chromium-review.googlesource.com/c/1339863
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57597}
GC needs to be able to read a bigint's length while the main thread may
change the length and the sign (bigints are intentionally mutable as
long as they haven't escaped to user code). Since both values are stored
in the same bitfield, we need to make these accesses atomic.
Also change right-trimming to not insert a filler when the object is
in large object space (it makes no sense there).
Bug: v8:8440
Change-Id: I72a1b6f1eda54566d3cfad554dda1a98ddd61975
Reviewed-on: https://chromium-review.googlesource.com/c/1337737
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57576}
This CL implements an assembly order optimization that moves blocks
that end a loop with an unconditional backedge to the beginning of
the loop, saving a branch.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I8a5d25f5472d71227af0f623277ea8d0a8d69867
Reviewed-on: https://chromium-review.googlesource.com/c/1335944
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57572}
With just five cache registers, Liftoff can run out of memory on a
64bit shift. This CL solves this by using a parallel register move and
pinning less registers.
R=ahaas@chromium.org
Bug: chromium:894307
Change-Id: I91ed0fee00ceb452841e5d1bb10905be6702dcce
Reviewed-on: https://chromium-review.googlesource.com/c/1337580
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57552}
When one of the inputs to NumberMin or NumberMax is NaN we need to
return NaN, ignoring whatever else was passed. Specifically we cannot
lower `NumberMin(x,y)` to `(x < y) ? x : y` if `x` can be NaN. So
limit this optimization to only perform the above lowering if we
know that `x` is an OrderedNumber and `y` is a PlainNumber (or if
the difference between zeros doesn't matter, an OrderedNumber as
well).
Bug: chromium:905457
Change-Id: If05f19255e14789ab0e277e072469c40e161b85b
Reviewed-on: https://chromium-review.googlesource.com/c/1337576
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57535}
This fixes several problems with instanceof and constant field tracking
in the compiler:
- properly bailout on numbers and non-functions at @@hasInstance.
- deopt on changes of @@hasInstance property.
Bug: v8:8361
Change-Id: I4a1cf9e29d72076f2d37a7c703f18cb2fb8f4040
Reviewed-on: https://chromium-review.googlesource.com/c/1322449
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57532}
This updates fast path checks in string's search/match/replace/split/matchAll
methods.
Bug: v8:8361
Change-Id: I0377aff21e380d6c718e7471f8964e10c030281b
Reviewed-on: https://chromium-review.googlesource.com/c/1333668
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57509}
