- 29 Jun, 2020 1 commit
-
-
Nico Hartmann authored
An 'arguments' array cannot be allocated in young space when its size exceeds kMaxRegularHeapObjectSize. In this case the optimizations in JSCreateLowering::ReduceJSCreateArguments are skipped. Bug: chromium:1098565 Change-Id: I30fdc78a1eb6e51fcd293785a46c9fd78995da9a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2273121Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#68585}
-
- 24 Jun, 2020 3 commits
-
-
Clemens Backes authored
This is a follow-up to https://crrev.com/c/2238569. R=cbruni@chromium.org No-Try: true Bug: v8:10556 Change-Id: Id667359a3098bf6e248716d33a8fcfc110236bb8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2262916Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68504}
-
Camillo Bruni authored
With this CL d8 exits with an error code if there is an unhandled promise rejection, e.g. due tue a failed assertion in a promise. Up until now these assertions were just ignored. Bug: v8:10556 Change-Id: I25f20e4be45a2de130562deb15f6a144f0ac976f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238569Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#68503}
-
Deepti Gandluri authored
The IsInBounds function is used in a few different places, when used for bounds checks on 32-bit platforms, size_t for max_memory_size leads to incorrect out of bounds accesses as size_t is not guaranteed to be 64-bit on all platforms. Use specific uint32_t, uint64_t methods for Wasm bounds checking instead of size_t. Bug: chromium:1080902 Change-Id: I0e21f0a310382c8ed0703c8302200d3352495c13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2256858 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68500}
-
- 23 Jun, 2020 1 commit
-
-
Andreas Haas authored
Due to recent spec changes, this CL removes the type immediate of ref.is_null again. Instead we check if the type of the input parameter is nullable. R=jkummerow@chromium.org Bug: v8:10556 Change-Id: If07d30fe4dd27664be7774422573b2ab2b0dfa20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247654 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#68484}
-
- 22 Jun, 2020 1 commit
-
-
Ng Zhi An authored
This changes the use of "sane" to "sensible" or "valid". I tried to be sensible in my choice of replacement, by trying to read the comments or code to see which word matches the intention closest. Referenced https://fuchsia.dev/fuchsia-src/contribute/best-practices/respectful_code?hl=en#what_are_examples_of_terminology_to_be_avoided. Bug: v8:10619 Change-Id: Id957b2e6ff11e95270e1372005e1006d8cf1008d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2254483 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#68471}
-
- 18 Jun, 2020 2 commits
-
-
Dan Elphick authored
When preparsing and detecting a sloppy block function redefinition then don't mark the variable as assigned to make it consistent with the eager parser. Bug: chromium:1053364 Change-Id: Iec7c24db80014bfe73ee41a4f3bb7a41a354cef2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241511 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#68415}
-
Michael Achenbach authored
This subsumes the old behavior of --allow-natives-for-fuzzing under --fuzzing as well. Both flags are used in a redundant way in fuzz configs. Only --allow-natives-for-fuzzing wasn't specified as a required argument, leading to the bug below. We still need the flag --allow-natives-for-differential-fuzzing to allow different functions when using differential fuzzing. Bug: chromium:1094866 Change-Id: I398791779e58ed4d80e896c1cfea343848159212 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2246568 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68401}
-
- 16 Jun, 2020 1 commit
-
-
Camillo Bruni authored
Bug: v8:10604 Change-Id: If66656017e53da34aa69bbe19d915df08cf6f332 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2246564 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#68368}
-
- 15 Jun, 2020 1 commit
-
-
Jakob Gruber authored
We recently changed uc32 to be an unsigned type, and with the invalid marker being static_cast<uc32>(-1) this DCHECK no longer holds. After this CL it expicitly checks for the invalid marker. Bug: v8:10568,chromium:1094226 Change-Id: Idd9efe055b38387e3e37b132cb786cca130767b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245592 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#68333}
-
- 10 Jun, 2020 2 commits
-
-
Jakob Gruber authored
Several uc32 (= int32_t) fields were incorrectly treated as uc16 (= uint16_t): CharacterRange::from() CharacterRange::to() QuickCheckDetails::Position::mask QuickCheckDetails::Position::value Bug: v8:10568 Change-Id: I9ea7d76e4a0cbc6ee681de2136c398cdc622bca2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2230527 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#68290}
-
Leszek Swirski authored
Previously, for the various customisation points of String builtins (like String.prototype.replace), we skipped the customisation symbol lookup (like for Symbol.replace) for Smis. But, we do need to do the lookup for Smis in case Number.prototype or Object.prototype have the Symbol. This missing lookup was creating an observable difference between Smis and HeapNumbers. Bug: chromium:1092896 Change-Id: I8928d237fa74abeaa2aa81318b8903087c507f0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238030 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68285}
-
- 09 Jun, 2020 2 commits
-
-
Manos Koukoutos authored
The reference types wasm proposal dropped all subtyping. Subsequently, the 'anyref' type was renamed to externref. This changes all references of the *type* anyref to externref. Additionally, the flag that permits this extension is renamed to "reftypes" to mirror the proposal name. Bug: v8:7748 Change-Id: Icf323f13b9660fd10540e65125af053fca3a03f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232941 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Kim-Anh Tran <kimanh@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#68270}
-
Nico Hartmann authored
A previous CL removed the kNoThrow flags from both SpeculativeBigIntAdd and SpeculativeBigIntSubtract. This introduced a bug, because the JSTypeHintLowering phase, where these operators are introduced during inlining, does not support the generation of throwing operators. Since these operators always deoptimize in case of an error, instead of throwing the exception directly, it is safe to mark them as kNoThrow. Bug: chromium:1091461 No-Try: true No-Tree-Checks: true Change-Id: I551616b0c462647574e5af8824d9ed7b3252659d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235113 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68254}
-
- 04 Jun, 2020 4 commits
-
-
Nico Hartmann authored
Speculative BigInt addition fails to throw the expected exception when called with non-BigInt inputs when the result of the computation is unused. In paricular, this CL does: - Remove kNoThrow on speculative BigInt operators - Fix AddWithFeedback to not lose type feedback if builtin throws to elide existing deopt loops - Add handling of TypeCheckKind in RepresentationChanger where this was previously ignored Bug: chromium:1073440 Change-Id: I953a5b790fc3b37a6824f0b6546a0488c51fbb3b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228493Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#68181}
-
Clemens Backes authored
This reverts commit b8f91666. Reason for revert: Fails gc-stress (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/28341). Original change's description: > [flags] warn about contradictory flags > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/ > > Bug: v8:10577 > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68168} TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org Change-Id: Ia1e3373fbb4c369594ceb98eb560e3ccf2cb8780 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10577 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2230523Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68169}
-
Tobias Tebbi authored
Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/ Bug: v8:10577 Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Tamer Tas <tmrts@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#68168}
-
Mythri A authored
We use StoreOwnIC to initialize the object after creating a new object with CreateObjectLiteral. CreateObjectLiteral stores kHoleNaNInt64 to indicate an uninitialized double field. When we actually try to store a NaN value into that field later using StoreOwnIC, IC avoids actually storing the new value since the existing value is "same as" the value we try to write. The float comparison treats all NaNs as equal. In this particular case, we should actually store the new value since kHoleNaNInt64 value is used to represent an uninitialized field. This cl just stores the new value even when the existing value is same as the new value for double fields. The check is still required to correctly track const fields. Bug: chromium:1082293 Change-Id: Ib37061802f2403545cffa6d6fef08be074b0825d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228886Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#68167}
-
- 03 Jun, 2020 3 commits
-
-
Andreas Haas authored
All subtyping has been removed from the reference-types proposal. This CL implements this proposal change now in V8. R=manoskouk@chromium.org Bug: v8:10556 Change-Id: I08ef064952278e03ea655461fa9f0c96426157c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2222345 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#68152}
-
Andreas Haas authored
Even in unreachable code, the targets of br_table have to have matching types. R=thibaudm@chromium.org Bug: v8:10556 Change-Id: I2e85df3cb92f7910a6bcb5ac03927c424194660d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218062 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#68148}
-
Andreas Haas authored
With recent changes to the anyref proposal, null refs now have a type immediate which declares the type of a null ref constant. Likewise, the RefIsNull instruction is type aware now. This CL addresses these proposal changes now. R=jkummerow@chromium.org Bug: v8:10556 Change-Id: I810dfa3a4ab4389afc9639f897cee5d43e9b62cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215172 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#68141}
-
- 02 Jun, 2020 2 commits
-
-
Clemens Backes authored
This reverts commit 76debfda. Reason for revert: Nullptr access in new test: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/37265 Original change's description: > [wasm-simd][liftoff] Fix I64x2Mul > > The I64x2Mul overwrote the lhs/rhs if they are the same as dst. So when > deciding if we need temporaries, we should not only check the > cache_state, but whether they alias dst or not. > > Bug: chromium:1088273 > Change-Id: I82efa9b45e0a3d321a06efde60971ce95b21490f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2225796 > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68114} TBR=clemensb@chromium.org,zhin@chromium.org Change-Id: I5fd337b71d82d262d36ff410077a11c17b50036b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1088273 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2226756Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68117}
-
Ng Zhi An authored
The I64x2Mul overwrote the lhs/rhs if they are the same as dst. So when deciding if we need temporaries, we should not only check the cache_state, but whether they alias dst or not. Bug: chromium:1088273 Change-Id: I82efa9b45e0a3d321a06efde60971ce95b21490f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2225796 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68114}
-
- 28 May, 2020 4 commits
-
-
Mythri A authored
Allocating a new feedback vector happens in two steps: We create an empty structure and then initialize the array based on the FeedbackMetadata.When allocating a new feedback array we could trigger a GC which might flush the bytecode and associated feedback metadata. This shouldn't happen in normal cases, because we either allocate feedback vector after compilation or when we reach the expected budget. In both cases, the age of the feedback vector should be 0 and hence bytecode shouldn't be flushed. However, with debugger enabled we may allocate feedback vectors even when the bytecode array is old for example: when we enable precise invocation counters. This also causes issues in tests with --stress-flush-bytecode. In the stress mode we flush bytecode without considering the age. Holding on to the feedback metadata prevents crashes in such cases. Bug: v8:10560 Change-Id: Ie806ff4102cb5fcf257c8683d5ca957853e38c05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218066 Commit-Queue: Mythri Alle <mythria@chromium.org> Auto-Submit: Mythri Alle <mythria@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#68052}
-
Mythri A authored
Temporarily disable stress-bytecode-flush on mjsunit/regress/regress-786784 while we investigate failures related to bytecode flushing. Bug: v8:10560 Change-Id: Ieb5cc7ba87da04133e98c6be25c9a499d79543e0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218038Reviewed-by:
Marja Hölttä <marja@chromium.org> Auto-Submit: Mythri Alle <mythria@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#68046}
-
Nico Hartmann authored
In BinaryOpAssembler::Generate_BinaryOperationWithFeedback, the feedback is stored only after the respective builtin/runtime call. If this call throws an exception, the feedback is lost, leading to a deopt loop in some cases. This CL fixes that issue by writing the gathered feedback before passing control to the builtin. Bug: chromium:1077197, v8:9441 Change-Id: I20e4b14815520224e2c6f8af1af6a89f754ccddf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202904 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#68038}
-
Nico Hartmann authored
This is a reland of 6204768b The original issue exposed the problem that NumberEqual performs implicit conversion of oddballs to numbers, which is incorrect for abstract equality comparison (i.e. 0 == null must not be true). This reland fixes this by applying the following steps: * Introduced a new kNumberOrBoolean value for CompareOperationFeedback, CompareOperationHint, TypeCheckKind and CheckedTaggedInputMode. * In CodeStubAssembler::Equal: Further distinguish between boolean and non-boolean oddballs and set feedback accoringly. * In JSTypedLowering: Construct [Speculative]NumberEqual operator with CompareOperationHint::kNumberOrBoolean, when this feedback is present. JSOperatorBuilder and operator cache are extended accordingly. * In SimplifiedLowering: Propagate a UseInfo with new TypeCheckKind::kNumberOrBoolean. * This leads to the generation of CheckedTaggedToFloat64 in RepresentationChanger with new CheckedTaggedInputMode::kNumberOrBoolean. * In EffectControlLinearizer: Handle this new mode. Accept and convert number and boolean and deopt for rest. Original change's description: > [turbofan] Improve equality on NumberOrOddball > > This CL cleans up CompareOperationFeedback by replacing it with a > composable set of flags. The interpreter is changed to collect > more specific feedback for abstract equality, especially if oddballs > are involved. > > TurboFan is changed to construct SpeculativeNumberEqual operator > instead of the generic JSEqual in many more cases. This change has > shown a local speedup of a factor of 3-10, because the specific > operator is way faster than calling into the generic builtin, but > it also enables additional optimizations, further improving > runtime performance. > > Bug: v8:5660 > Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854 > Reviewed-by: Mythri Alle <mythria@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67645} TBR: tebbi@chromium.org Bug: v8:5660 Change-Id: I12e733149a1d2773cafb781a1d4b10aa1eb242a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193713 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68037}
-
- 26 May, 2020 1 commit
-
-
Daniel Clifford authored
There was a legacy place in map code that wasn't fully ported to use the strong, new SloppyArgumentsElements type because of code that used hard-coded constants. Bug: chromium:1086470 Change-Id: Ieba152e4bd92c89125f831949c2efb4f4219f95c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215059Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#67984}
-
- 25 May, 2020 1 commit
-
-
Ross McIlroy authored
We can't consistently rewire the successor blocks of an unreachable node to disconnect them from the graph when we are trying to maintain the schedule. Instead simply leave the code there. As a future optimization we could add a proper scheduled dead code elimination phase which can deal with this. As a side-effect, one of the tests sees a int64 DeadValue, so add support for that in the instruction selector. BUG=chromium:1083272,chromium:1083763,chromium:1084953,v8:9684 Change-Id: I69a6feaeef4eae62110392e27ea848b28bccf787 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209061 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#67953}
-
- 21 May, 2020 1 commit
-
-
Ng Zhi An authored
The proposal uses the lane shape, e.g. i64x2.anytrue, and we were using s1x2.anytrue in our opcodes. This was a legacy naming, because we were trying to bitpack the booleans. Now that we aren't doing that, rename these to be more consistent with the proposal. This was done with a straightforward sed script, changing both cpp code and also some comments in mjsunit test files. Bug: v8:10506 Change-Id: If077ed805de23520d8580d6b3b1906c80f67b94f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207915 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67945}
-
- 20 May, 2020 1 commit
-
-
Jakob Gruber authored
This was introduced by https://crrev.com/c/2207137. Load offsets can be negative. Drive-by: Add a helper function to wrap the verbose static casts in bounds checks. Bug: chromium:1084872,chromium:1083450 Change-Id: I48934d04a8ab15a8fc347465064b190e32c00716 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209066 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#67924}
-
- 19 May, 2020 3 commits
-
-
Thibaud Michaud authored
Registers cannot be used as a merge destination if they have more than one use, otherwise the merge will unexpectedly affect other uses of that register. R=ahaas@chromium.org,clemensb@chromium.org Bug: chromium:1084151 Change-Id: I0d6ad97c585920357a37d95361e0320d32c71f4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208851Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67904}
-
Jakob Gruber authored
So far this is mainly a readability improvement to specify expectations on the packed argument. In the future we should also check signedness during bytecode generation. Drive-by: Update DCHECK to allow signed args to CHECK_CURRENT_POSITION. Bug: chromium:1083450 Change-Id: I9376ec691b51eb251c972309ad65dd6c04eec3ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207137 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#67880}
-
Ng Zhi An authored
The lowering for anytrue was assuming that the input nodes are all integers. The regression test added in https://crrev.com/c/2194471 calls anytrue with float operands, this was causing the lowering to generate cmpl instructions with a float register and an immediate, which is wrong. The fix is to use GetReplacementsWithType on the input nodes, but only if the input were floats, since we use Word32Equal. Drive-by clean up of comments in the aforementioned regression test. Bug: v8:10535 Change-Id: I4de89516c178e9003a4c745808d831be87918381 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203400 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#67878}
-
- 14 May, 2020 1 commit
-
-
Ross McIlroy authored
The scheduler could schedule unreachable nodes on two basic blocks that later merge. Update DCHECK in graph-assembler's basic block updater to only check for the self-containedness of unreachable basic blocks removed from the schedule after all the blocks have been re-written to allow for this case. BUG=chromium:1079446,v8:9684 Change-Id: I91899dbf389e4425542dbd2b1ca95c3f6ad79c05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196354Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#67812}
-
- 13 May, 2020 2 commits
-
-
Ng Zhi An authored
The AVX implementation does not have dst == input(0), so the vminps call was wrong. The intention is to compare the 2 input operands. Bug: chromium:1081030 Change-Id: Id54074327a6aca4b75988fc9d85beccfeabfc791 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194471Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67786}
-
Igor Sheludko authored
... when one of the receivers is a JSArray that may have a read-only length. Bug: chromium:1069530 Change-Id: Idbaf1a9030bb5a0f9c25e30925f18f603a99832f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196353Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#67783}
-
- 12 May, 2020 1 commit
-
-
Jakob Gruber authored
Prior to this CL we still implemented a HasProperty-GetProperty sequence when accessing named captures in GetSubstitution. This was briefly part of the spec (we also threw an exception when the property was not present), but since late 2017 the GetProperty call has been unconditional. See https://tc39.es/ecma262/#sec-getsubstitution. Bug: v8:10513 Change-Id: Id82c06958b0b0feffc6eede580b99ab8676a0dae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2195821 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#67733}
-
- 11 May, 2020 2 commits
-
-
Igor Sheludko authored
... when the element is read-only in one of the prototypes: * the length should not be updated, * in strict mode the store operation should throw TypeError. Bug: chromium:1055138 Change-Id: I7fc08e22c83f8a9848053cfe20851dc1b82f0e3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172090 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67717}
-
Toon Verwaest authored
Scripts aren't callable functions. Even though internally they were for a while, they aren't anymore. We shouldn't return them to users as if they were. We already remove strict-mode functions from CallSites, so we now do the same for internal functions that are created for scripts. Bug: v8:10508 Change-Id: I270c714524439fba9ad90dd29826bed4811ba2b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193716 Auto-Submit: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67709}
-