Extend the flag parameter with a bit that decides if the input should
be converted (-0 to 0, and a string to the array index it represents).
Instruct redundancy elimination to never replace x with CheckBounds(x)
when this CheckBounds is of the converting kind.
Bug: chromium:1070892, chromium:1071743
Change-Id: I3125a6e267d56dae6bf6cb2f5f52d27ef65d7c79
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157365
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67408}
This relands commit 1a38573f9d.
The original change used a sequence of instruction in the test that
could not be scalar lowered properly.
Original change's description:
> [arm] Change fp_fixed registers to be allocatable registers
>
> fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
> need to be allocatable, so that they can be correctly marked as fixed
> and spilled as required. The previous value of fp_fixed2, d29, is not in
> the list of allocatable double registers, and not marked as fixed
> appropriately.
>
> One fix could be to extend the list of allocatable double registers, but
> there is a comment there saying that the list is kept even-length to
> make stack alignment easier. So rather than messing with that, we
> instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
> the only user, this is a simpler change.
>
> Bug: chromium:1070078
> Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67372}
Bug: chromium:1070078
Change-Id: I02bb4b3ad03817318cbd0ee706c5ef4f20c845ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165867
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67406}
This patch has the following improvement on v8.browsing_mobile:
- total-main-thread:duration improved by 1.7%
- js:duration improved by 1.3%
Change-Id: I1cdf2c181bfd991b67f31c5c2f32e3c2f909c67e
Bug: v8:9684, v8:10431
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149433
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67405}
This adds a test which I suspected would fail, but luckily it doesn't.
The idea is to catch a proper wasm exception in JS, then construct a new
exception, but set the catched exception as the prototype. My suspicion
was that we would still handle that new exception like a wasm exception,
since the `WasmExceptionGetTag` and `WasmExceptionGetValues` runtime
functions to a standard property lookup, which includes a prototype
walk.
Interestingly, the prototype walk is already skipped automatically when
loading private symbols, so the implementation already supports this
case correctly.
Let's still add this test to have coverage for this case.
R=jkummerow@chromium.orgCC=aheejin@chromium.org
Bug: v8:8091
Change-Id: Idf9944cf47f96cca38e9678e9200bf03a39ea126
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2167438
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67391}
This reverts commit 390ed4b934.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/36714?
Original change's description:
> [arm] Change fp_fixed registers to be allocatable registers
>
> fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
> need to be allocatable, so that they can be correctly marked as fixed
> and spilled as required. The previous value of fp_fixed2, d29, is not in
> the list of allocatable double registers, and not marked as fixed
> appropriately.
>
> One fix could be to extend the list of allocatable double registers, but
> there is a comment there saying that the list is kept even-length to
> make stack alignment easier. So rather than messing with that, we
> instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
> the only user, this is a simpler change.
>
> Bug: chromium:1070078
> Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67372}
TBR=gdeepti@chromium.org,zhin@chromium.org,thibaudm@chromium.org
Change-Id: I00b4b34771b5832cc3d5fe6eac7aac506ec82d50
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1070078
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165865
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67375}
fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
need to be allocatable, so that they can be correctly marked as fixed
and spilled as required. The previous value of fp_fixed2, d29, is not in
the list of allocatable double registers, and not marked as fixed
appropriately.
One fix could be to extend the list of allocatable double registers, but
there is a comment there saying that the list is kept even-length to
make stack alignment easier. So rather than messing with that, we
instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
the only user, this is a simpler change.
Bug: chromium:1070078
Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67372}
If module bytes end in a prefix like 0xfc (numeric prefix), we read out
of bounds (pc + 1). So, if validate flag is set, check the length.
Bug: chromium:1073553
Change-Id: Ia9771419d01f2315723d19dd96630172b5a7a1f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161404
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67370}
This is a reland of 29c1eab92e
Original change's description:
> [builtins] Clean up the use of class_name / ES5 [[Class]]
>
> Before ES2015, the ES spec had a [[Class]] internal slot for all
> objects, which Object.prototype.toString() would use to figure the
> returned string. Post-ES2015, the [[Class]] slot was removed in spec for
> all objects, with the @@toStringTag well-known symbol the proper way to
> change Object.prototype.toString() output.
>
> At the time, spec-identical handling without the use of [[Class]] was
> implemented in V8 for all objects other than API objects, where issues
> with the Web IDL spec [1] prevented Blink, and hence V8, to totally
> migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
> @@toStringTag on API class prototypes to manage the
> Object.prototype.toString() output, so the legacy [[Class]] handling in
> V8 has not been necessary for the past couple of years.
>
> This CL removes the remaining legacy [[Class]] handling in
> Object.prototype.toString(), JSReceiver::class_name(), and
> GetConstructorName(). However, it does not remove the class_name field
> in FunctionTemplateInfo, as it is still used for the `name` property of
> created functions.
>
> This CL also cleans up other places in the codebase that still reference
> [[Class]].
>
> This change should have minimal impact on web-compatibility. For the
> change to be observable, a script must do one of the following:
>
> 1. delete APIConstructor.prototype[Symbol.toStringTag];
> 2. Object.setPrototypeOf(apiObject, somethingElse);
>
> Before this CL, these changes will not change the apiObject.toString()
> output. But after this CL, they will make apiObject.toString() show
> "[object Object]" (in the first case) or the @@toStringTag of the other
> prototype (in the latter case).
>
> However, both are deemed unlikely. @@toStringTag is not well-known
> feature of JavaScript, nor does it get tampered much on API
> constructors. In the second case, setting the prototype of an API object
> would effectly render the object useless, as all its methods (including
> property getters/setters) would no longer be accessible.
>
> Currently, @@toStringTag-based API object branding is not yet
> implemented by other browsers. This V8 bug in particular has been an
> impediment to standardizing toString behavior. Fixing this bug will
> unblock [3] and lead to a better Web IDL spec, and better toString()
> compatibility for all.
>
> [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
> [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
> [3]: https://github.com/heycam/webidl/pull/357
>
> Bug: chromium:793406
> Cq-Include-Trybots: luci.chromium.try:linux-rel
> Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67327}
Bug: chromium:793406
Change-Id: Ia5d97bd4e1c44cadc6f18a17ffc9d06b038cf8f1
Cq-Include-Trybots: luci.chromium.try:linux-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163881
Auto-Submit: Timothy Gu <timothygu@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67361}
This reverts commit 29c1eab92e.
Reason for revert: Causes Blink test failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4222
Original change's description:
> [builtins] Clean up the use of class_name / ES5 [[Class]]
>
> Before ES2015, the ES spec had a [[Class]] internal slot for all
> objects, which Object.prototype.toString() would use to figure the
> returned string. Post-ES2015, the [[Class]] slot was removed in spec for
> all objects, with the @@toStringTag well-known symbol the proper way to
> change Object.prototype.toString() output.
>
> At the time, spec-identical handling without the use of [[Class]] was
> implemented in V8 for all objects other than API objects, where issues
> with the Web IDL spec [1] prevented Blink, and hence V8, to totally
> migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
> @@toStringTag on API class prototypes to manage the
> Object.prototype.toString() output, so the legacy [[Class]] handling in
> V8 has not been necessary for the past couple of years.
>
> This CL removes the remaining legacy [[Class]] handling in
> Object.prototype.toString(), JSReceiver::class_name(), and
> GetConstructorName(). However, it does not remove the class_name field
> in FunctionTemplateInfo, as it is still used for the `name` property of
> created functions.
>
> This CL also cleans up other places in the codebase that still reference
> [[Class]].
>
> This change should have minimal impact on web-compatibility. For the
> change to be observable, a script must do one of the following:
>
> 1. delete APIConstructor.prototype[Symbol.toStringTag];
> 2. Object.setPrototypeOf(apiObject, somethingElse);
>
> Before this CL, these changes will not change the apiObject.toString()
> output. But after this CL, they will make apiObject.toString() show
> "[object Object]" (in the first case) or the @@toStringTag of the other
> prototype (in the latter case).
>
> However, both are deemed unlikely. @@toStringTag is not well-known
> feature of JavaScript, nor does it get tampered much on API
> constructors. In the second case, setting the prototype of an API object
> would effectly render the object useless, as all its methods (including
> property getters/setters) would no longer be accessible.
>
> Currently, @@toStringTag-based API object branding is not yet
> implemented by other browsers. This V8 bug in particular has been an
> impediment to standardizing toString behavior. Fixing this bug will
> unblock [3] and lead to a better Web IDL spec, and better toString()
> compatibility for all.
>
> [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
> [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
> [3]: https://github.com/heycam/webidl/pull/357
>
> Bug: chromium:793406
> Cq-Include-Trybots: luci.chromium.try:linux-rel
> Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67327}
TBR=verwaest@chromium.org,timothygu@chromium.org
Change-Id: I678d2ffc1064b1d1ddb62024cc23c6c41b216ef4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:793406
Cq-Include-Trybots: luci.chromium.try:linux-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163956
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67349}
Before ES2015, the ES spec had a [[Class]] internal slot for all
objects, which Object.prototype.toString() would use to figure the
returned string. Post-ES2015, the [[Class]] slot was removed in spec for
all objects, with the @@toStringTag well-known symbol the proper way to
change Object.prototype.toString() output.
At the time, spec-identical handling without the use of [[Class]] was
implemented in V8 for all objects other than API objects, where issues
with the Web IDL spec [1] prevented Blink, and hence V8, to totally
migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
@@toStringTag on API class prototypes to manage the
Object.prototype.toString() output, so the legacy [[Class]] handling in
V8 has not been necessary for the past couple of years.
This CL removes the remaining legacy [[Class]] handling in
Object.prototype.toString(), JSReceiver::class_name(), and
GetConstructorName(). However, it does not remove the class_name field
in FunctionTemplateInfo, as it is still used for the `name` property of
created functions.
This CL also cleans up other places in the codebase that still reference
[[Class]].
This change should have minimal impact on web-compatibility. For the
change to be observable, a script must do one of the following:
1. delete APIConstructor.prototype[Symbol.toStringTag];
2. Object.setPrototypeOf(apiObject, somethingElse);
Before this CL, these changes will not change the apiObject.toString()
output. But after this CL, they will make apiObject.toString() show
"[object Object]" (in the first case) or the @@toStringTag of the other
prototype (in the latter case).
However, both are deemed unlikely. @@toStringTag is not well-known
feature of JavaScript, nor does it get tampered much on API
constructors. In the second case, setting the prototype of an API object
would effectly render the object useless, as all its methods (including
property getters/setters) would no longer be accessible.
Currently, @@toStringTag-based API object branding is not yet
implemented by other browsers. This V8 bug in particular has been an
impediment to standardizing toString behavior. Fixing this bug will
unblock [3] and lead to a better Web IDL spec, and better toString()
compatibility for all.
[1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
[2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
[3]: https://github.com/heycam/webidl/pull/357
Bug: chromium:793406
Cq-Include-Trybots: luci.chromium.try:linux-rel
Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67327}
There's no reason for it to be a JSArray; it's an internal data member.
We only have a slow version for constructing a FixedArray from an
Iterable, but since this is not a performance critical code path,
it's fine.
BUG=v8:9808
Change-Id: I5bcfac4cc545880966421a96d3aa3d899bbf6cd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157371
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67321}
This is a reland of 80843eda31
Original change's description:
> [torque] Allow storing to bitfield structs that are stored in Smis
>
> This change:
> 1. Updates the Torque compiler to allow direct access to bitfields that
> are packed within Smi values, which previously would have required a
> separate untagging step,
> 2. Updates JSRegExpStringIterator to represent its flags in Torque,
> 3. Adds reduction cases in MachineOperatorReducer for when the input to
> a branch or the left-hand side of a Word32Equals is based on a 64-bit
> shift-and-mask operation which has been truncated to 32 bits, as is
> the case in the code generated by step 1, and
> 4. Adds a reduction case in MachineOperatorReducer to remove an extra
> Word64And operation added by step 1.
>
> Bug: v8:7793
> Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67290}
Bug: v8:7793
Change-Id: I783b6ec080042fec0e922927f6675dede458a072
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159731
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67305}
This reverts commit 80843eda31.
Reason for revert: Causes compilation failure on macs
https://ci.chromium.org/p/v8/builders/ci/Mac%20V8%20FYI%20Release%20(Intel)/8934?
Original change's description:
> [torque] Allow storing to bitfield structs that are stored in Smis
>
> This change:
> 1. Updates the Torque compiler to allow direct access to bitfields that
> are packed within Smi values, which previously would have required a
> separate untagging step,
> 2. Updates JSRegExpStringIterator to represent its flags in Torque,
> 3. Adds reduction cases in MachineOperatorReducer for when the input to
> a branch or the left-hand side of a Word32Equals is based on a 64-bit
> shift-and-mask operation which has been truncated to 32 bits, as is
> the case in the code generated by step 1, and
> 4. Adds a reduction case in MachineOperatorReducer to remove an extra
> Word64And operation added by step 1.
>
> Bug: v8:7793
> Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67290}
TBR=tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org
Change-Id: Ifa683c92631291c9437438682b6efb2e12862682
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159730
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67291}
This change:
1. Updates the Torque compiler to allow direct access to bitfields that
are packed within Smi values, which previously would have required a
separate untagging step,
2. Updates JSRegExpStringIterator to represent its flags in Torque,
3. Adds reduction cases in MachineOperatorReducer for when the input to
a branch or the left-hand side of a Word32Equals is based on a 64-bit
shift-and-mask operation which has been truncated to 32 bits, as is
the case in the code generated by step 1, and
4. Adds a reduction case in MachineOperatorReducer to remove an extra
Word64And operation added by step 1.
Bug: v8:7793
Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67290}
We give the optimized code another chance on soft deopts in TurboProp.
If the deopt is happening on infrequently taken paths, then this will
let us reuse the optimized code for the subsequent executions. If the
soft deopts are happening multiple times on the same code, then we would
discard the optimized code. The number of deopts we would wait is
controlled by FLAG_reuse_opt_code_count.
BUG=v8:10433
Change-Id: Iaadea4cffde7d7d55be4875c9586694dca64957c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093503
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67289}
This reverts commit f442b03fe2.
Reason for reland: Wrongly reverted.
Original change's description:
> Revert "[turbofan] Fix bug in Number.Min/Max typings"
>
> This reverts commit 4158af83db.
>
> Reason for revert: causing UBSAN failures:
>
> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729?
>
>
> Original change's description:
> > [turbofan] Fix bug in Number.Min/Max typings
> >
> > They try to be very precise about when the result can be -0,
> > but do so incorrectly. I'm changing the code to just do the
> > simple thing instead. Let's see how that affects performance.
> >
> > Bug: chromium:1072171
> > Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#67246}
>
> TBR=neis@chromium.org,tebbi@chromium.org
>
> Change-Id: I0d9b312e27f5a8bbbebeccdc9819fa94f10af139
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1072171
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157646
> Reviewed-by: Francis McCabe <fgm@chromium.org>
> Commit-Queue: Francis McCabe <fgm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67249}
TBR=neis@chromium.org,tebbi@chromium.org,fgm@chromium.org
Change-Id: Ida36ca584a5af5da887189328c8da195b26285d4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1072171
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157368
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67263}
This reverts commit 4158af83db.
Reason for revert: causing UBSAN failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729?
Original change's description:
> [turbofan] Fix bug in Number.Min/Max typings
>
> They try to be very precise about when the result can be -0,
> but do so incorrectly. I'm changing the code to just do the
> simple thing instead. Let's see how that affects performance.
>
> Bug: chromium:1072171
> Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67246}
TBR=neis@chromium.org,tebbi@chromium.org
Change-Id: I0d9b312e27f5a8bbbebeccdc9819fa94f10af139
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1072171
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157646
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67249}
They try to be very precise about when the result can be -0,
but do so incorrectly. I'm changing the code to just do the
simple thing instead. Let's see how that affects performance.
Bug: chromium:1072171
Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67246}
The fast store handlers create elements and if we have a typed array
on the prototype chain it is not easy to check when it is OK to create
new elements. The TypedArrays swallow all OOB stores, and there is no
easy way to check if the current store is OOB for JSObjects. So use
slow stub when there are typed arrays on the prorotype chain of
JSObjects.
Bug: chromium:1068492
Change-Id: I9eea9cf00e3eb84931c5545d18ba53c4ec39f353
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134138
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67226}
A new realm doesn't contain the mocks and suppressions on the global
object for correctness fuzzing. We replace Realm.eval with eval to
keep exercising the code.
Bug: chromium:1071133
Change-Id: Iffe82d37bf08829fc5937c17c2089277403e71dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153206
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67187}
SIMD opcodes consist of the prefix byte, then an LEB128 encoded int. We
were decoding this incorrectly as a fixed uint8. This fixes the decoder
to properly handle multi bytes.
In some cases, the multi byte logic is applied to all prefixed opcodes.
This is not a problem, since for values < 0x80, the LEB encoding is a
single byte, and decodes to the same int. If the prefix opcode has
instructions with index >= 0x80, it would be required to be LEB128
encoded anyway.
There are a bunch of trivial changes to test-run-wasm-simd, to change
the macro from BUILD to BUILD_V, the former only works for single byte
opcodes, the latter is a new template-based macro that correct handles
multi-byte opcodes. The only unchanged test is the shuffle fuzzer test,
which builds its own sequence of bytes without using the BUILD macro.
Bug: v8:10258
Change-Id: Ie7377e899a7eab97ecf28176fd908babc08d0f19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118476
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67186}
When we create a new elements array we should initialize it with holes.
The capacity of the newly created elements array could be greater than
the actual length of the array and we expect the unused slots to be
filled with holes.
Bug: chromium:1070560
Change-Id: Ia365eed59859e36a9c8b9e27be34f93ab88942bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150599
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67180}
Change-Id: Ic5dbf4c3330c71cbae73aa07b2adb1c8ac087182
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151348
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67172}
Soft-deopt for mono/polymorphic property accesses that don't have any
maps, and only allow zero-map feedback to be monomorphic. This makes
sure we only emit a megamorphic LoadIC builtin call if the IC was
actually megamorphic.
JSGenericLowering assumed that zero maps meant that a load site is
megamorphic. However, it can be the case that the call-site is
monomorphic or polymorphic, and the maps had died. In this case we don't
want to call the megamorphic IC builtin, as on a stub cache miss we
fallback to a normal LoadIC miss, which can record mono/polymorphic
feedback in the IC. After this, we'll enter a miss loop in the
megamorphic load builtin, and worse the LoadIC assumes that there's
something "wrong" with the feedback, so it'll keep trying to reconfigure
the handler (possibly allocating new load handlers if this is a
prototype field access).
As a drive-by, rewrite GetRelevantReceiverMaps to be an in-place
filtering of the maps rather than copying them.
Change-Id: I0c25bfa606367fa81c43223bbd56cdadb5e789ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150586
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67152}
In strict mode stores to non-existent properties throw. We should not
install a handler with the property cell for such stores. These handlers
would expect that the value exists when they see a property cell. If
this property cell gets invalidated later, it appears as if it is a
valid property cell with undefined value. This leads to an incorrect
behaviour. This cl checks if we are in strict mode and uses a slow
stub in such cases.
Bug: chromium:1067757
Change-Id: I543c6a6931530bfb13cc9a33d1dabaa756489fd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142255
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67151}
Bug: chromium:1070890
Change-Id: I62ad81b8d5bcb9934c7eda4eae595d41339adfdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149425
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67147}
When memory.grow was executed concurrently on multiple threads a data
race could happen such that two memory.grow operations result in the
same return value. With this CL the return value of memory.grow is
unique, given that memory.grow actually grows the memory.
As a concrete example, assume a shared WebAssembly memory initially has
a size of 100. Assume two threads call memory.grow concurrently with a
parameter `10`. Then with the existing code, memory would grow correctly
to a size of 120, but the data race may cause both memory.grow
operations to return 100. With the change in this CL one memory.grow
operation would return 100, the other would return 110.
R=gdeepti@chromium.orgCC=rreverser@google.com
Bug: chromium:1067621
Change-Id: Ib22b5135714a56799e0818ccb39e5dce327e5f8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144113
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67135}
For example, when --fuzzing is off, %OptimizeFunctionOnNextCall now
crashes when given a non-function argument.
The following behaviors remain unchanged for now:
- %DeoptimizeFunction continues to do nothing if the function is not
optimized.
- %DeoptimizeNow continues to do nothing if the top-most JS function
is not optimized.
- %OptimizeOSR continues to do nothing if the function already has
optimized code.
Bug: v8:10249
Change-Id: I35d2f3d50ce3f94c8ffccabe50fb4df2b70ce028
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137406
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67121}
This is a reland of f902ef3257
Original change's description:
> [wasm] Cleanup wasm script creation
>
> - Do not expose CreateWasmScript since we should now use
> WasmEngine:GetOrCreateScript instead,
> - Initialize all Script fields in CreateWasmScript, not in
> WasmModuleObject::New,
> - Do not pass code size estimate argument, since we can always use the
> actual native module's committed code space.
>
> R=clemensb@chromium.org
>
> Bug: v8:10349
> Change-Id: If9250d62ffc271ab6efc3b9c45958a305c9d1827
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135633
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67083}
Bug: v8:10349
Change-Id: I38c8b6beb07a1e5d565c6a5fd749daea147817bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144064
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67087}
This reverts commit f902ef3257.
Reason for revert: Makes gc-stress unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/27404
Original change's description:
> [wasm] Cleanup wasm script creation
>
> - Do not expose CreateWasmScript since we should now use
> WasmEngine:GetOrCreateScript instead,
> - Initialize all Script fields in CreateWasmScript, not in
> WasmModuleObject::New,
> - Do not pass code size estimate argument, since we can always use the
> actual native module's committed code space.
>
> R=clemensb@chromium.org
>
> Bug: v8:10349
> Change-Id: If9250d62ffc271ab6efc3b9c45958a305c9d1827
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135633
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67083}
TBR=clemensb@chromium.org,thibaudm@chromium.org
Change-Id: Iac2978af1a300ec079baebab0feb8c9598711738
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10349
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144058
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67085}
- Do not expose CreateWasmScript since we should now use
WasmEngine:GetOrCreateScript instead,
- Initialize all Script fields in CreateWasmScript, not in
WasmModuleObject::New,
- Do not pass code size estimate argument, since we can always use the
actual native module's committed code space.
R=clemensb@chromium.org
Bug: v8:10349
Change-Id: If9250d62ffc271ab6efc3b9c45958a305c9d1827
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135633
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67083}
Apple currently objects to cleanupSome but agrees to shipping the rest
of WeakRefs. Separate out cleanupSome to its own flag so the rest of
WeakRefs may ship.
Bug: v8:8179
Change-Id: I6159fc743c9cb658860d4260b0dcb95e54630fdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2141011
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67070}
JSNativeContextSpecialization lowered this operator to a regular
property store, potentially ignoring a request to set the "name"
property of a function.
This CL performs the lowering only if there's no such request.
Bug: chromium:1068494
Change-Id: Ia2eaf05af9c8402f9e6450ee519a7c36c18cd44e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139581
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67058}
This relands commit 7d955faa76.
Changed the test case to use i16x8 splat instead of i8x16 splat,
the latter was causing issues when doing scalar lowering. This
change still causes the regression test to fail without the fix.
Original change's description:
> [wasm-simd][x64][ia32] Do not overwrite input register
>
> We are ovewriting input register (contains the shift) when we are
> masking it, instead, move to a temporary,then mask it.
>
> Bug: chromium:1065599
> Change-Id: Iab72b94581239447e444746681387350b576e24a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2125941
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66997}
Bug: chromium:1065599
Change-Id: I0dc78ddb013652ef88c07d065c3f6877937c5300
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2136220
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67026}
This is a minimal version of https://crrev.com/c/2135642 intended for
backmerges.
Ensure that the interpreter has space for all required registers.
Bug: chromium:1067270
Change-Id: Iefd016b4845fb8698d1e0ef5f6a03df0e66aa576
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137403
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67013}
Typed array iteration throws a TypeError if the receiver is not
a typed array. The JSCallReducer didn't take that into account.
Bug: chromium:1067544
Change-Id: Ib065ba1b7881dc0b62242fc416fa16023a7fa244
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135632
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67010}
This reverts commit 7d955faa76.
Reason for revert: Bad change, modified wrong test file https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/36416
Original change's description:
> [wasm-simd][x64][ia32] Do not overwrite input register
>
> We are ovewriting input register (contains the shift) when we are
> masking it, instead, move to a temporary,then mask it.
>
> Bug: chromium:1065599
> Change-Id: Iab72b94581239447e444746681387350b576e24a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2125941
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66997}
TBR=gdeepti@chromium.org,zhin@chromium.org
Change-Id: I50c57906d6eb49758584b477c971179ea3c6e5d3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1065599
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134655
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67000}
We are ovewriting input register (contains the shift) when we are
masking it, instead, move to a temporary,then mask it.
Bug: chromium:1065599
Change-Id: Iab72b94581239447e444746681387350b576e24a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2125941
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66997}
For keyed stores we recompute handlers based on the receiver maps
we have seen. This is done so that we can transition to the most generic
elements kind we have seen so far. When we recompute this handlers we
get a new prototype validity cell and ignore the existing cell. This
leads to incorrect behaviour if the cell was invalid. Recomputing the
handler may be extra work which is not worth doing at this point. So
we just reuse the existing validity cell and let the IC recompute the
handler if we see the map again.
Bug: chromium:1053939
Change-Id: Ifc891d70f5a4b8b774238e12fb40e29b4d174e37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122032
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66963}
Double literals without dots should still be parsed as double constants,
not unsigned constants. The static_cast would remove the fractional
part, making constants like "1e-15" come out as "0" unsigned constants.
The precise semantics is not spec'ed, so we still consider literals like
"1e1" to be unsigned, and only switch to double if there is a fractional
part.
R=ecmziegler@chromium.org
Bug: chromium:1065635
Change-Id: I0aac018058a149632e0849572d19fdcc7b2af7aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126922
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66949}
