- 10 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... by migrating old-style code MyObject* obj = new (zone) MyObject(...) to the new style MyObject* obj = zone->New<MyObject>(...) Bug: v8:10689 Change-Id: I55c686bbedfa1fd1955a5927df3f72b366312fd4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288867 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68808}
-
- 27 Apr, 2020 1 commit
-
-
Georg Neis authored
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}
-
- 20 Apr, 2020 1 commit
-
-
Tobias Tebbi authored
Change-Id: Ic372c7b7b308650518d0ddf938c389cfb7c2ea07 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137407 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67248}
-
- 29 Feb, 2020 1 commit
-
-
Mike Stanton authored
We can make better inlining decisions in TurboFan if the CallIC will provide the feedback that it's seen multiple closures that share the same SharedFunctionInfo. This is not difficult to do, and it fixes some frustrating performance cliffs. Thanks to Bmeurer@chromium.org for the prototype CL, rebased from his project a year ago. Bug: v8:2206, v8:10100 Change-Id: I4248145ea67216f9a23efa175bbe90e7a9ee0ec4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054100 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66512}
-
- 13 Jan, 2020 1 commit
-
-
Tobias Tebbi authored
This is an improved version of https://chromium-review.googlesource.com/c/v8/v8/+/1981507 Bug: chromium:1031909 Change-Id: I552f49bf87340eee3c85fa02893b8e63a77a3608 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997129Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65722}
-
- 07 Jan, 2020 1 commit
-
-
Tobias Tebbi authored
Bug: chromium:1031909 Change-Id: Ibf120d722a8cb6eb9b9eaa15163cb7846dab64ea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981507Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65599}
-
- 11 Nov, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Including but not limiting to removing: * BitcastCompressedXXX * CheckedCompressedXXX * ChangeXXXToCompressedYYY * ChangeCompressedXXX As a note, ChangeTaggedToCompressed can't be removed just yet as it is still in use. Bug: v8:7703 Change-Id: I98cf88a32adfa976d419e69702d1cac4d3e811a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903435 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64880}
-
- 16 Oct, 2019 1 commit
-
-
Sathya Gunasekaran authored
Updates CSA::TryToIntptr to handle array indices that are less than INT_MAX which allows to handle string keys in the ICs. Updates ICs to go monomorphic for string keys that are array indices. Updates Turbofan to handle array indices when lowering element access. Change-Id: Ibdde20130e075d0d645ab4a8266a968335eaad84 Bug: v8:9449 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813018Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64320}
-
- 23 Jul, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Also add tests for it. Drive-by fix: Use ChangeInt32ToCompressedSmi since we have it 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: I45f04f8857acfc57b69eb4022a24ba082d28a91f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708480Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#62871}
-
- 12 Jul, 2019 1 commit
-
-
Nico Hartmann authored
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}
-
- 02 Jul, 2019 1 commit
-
-
Nico Hartmann authored
Operations on BigInts, for which TurboFan statically knows that they are no larger than 2^64, can be lowered to efficient machine code in TurboFan. This is the first step in doing so by generating efficient code for asUintN and the required checks and conversions. Bug: v8:9407 Change-Id: I51f6505f6c4567434fa369fcf870a09871487f51 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680548 Commit-Queue: Nico Hartmann <nicohartmann@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62488}
-
- 26 Jun, 2019 1 commit
-
-
Nico Hartmann authored
This is a reland of 5ff38bae Original change's description: > [TurboFan] Fast path for JSAdd with BigInt feedback > > This CL introduces the necessary infrastructure to generate speculative > BigInt operations in case of BigInt feedback. In particular, the JSAdd > operator is lowered to a speculative call to the BigIntAdd builtin, > with a deopt bailout in case of exceptions or violated assumptions. > > Bug: v8:9213 > Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 > Commit-Queue: Nico Hartmann <nicohartmann@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62362} Bug: v8:9213 Change-Id: Ic0caf7aab2103b8f5e22a504427e8604cc894d75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677209Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@google.com> Cr-Commit-Position: refs/heads/master@{#62381}
-
- 25 Jun, 2019 2 commits
-
-
Francis McCabe authored
This reverts commit 5ff38bae. Reason for revert: flaky test that is not normally flaky failed. See: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20nosnap%20-%20debug/24531 Original change's description: > [TurboFan] Fast path for JSAdd with BigInt feedback > > This CL introduces the necessary infrastructure to generate speculative > BigInt operations in case of BigInt feedback. In particular, the JSAdd > operator is lowered to a speculative call to the BigIntAdd builtin, > with a deopt bailout in case of exceptions or violated assumptions. > > Bug: v8:9213 > Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 > Commit-Queue: Nico Hartmann <nicohartmann@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62362} TBR=jarin@chromium.org,neis@chromium.org,sigurds@chromium.org,nicohartmann@google.com Change-Id: I5ae63a0183283894b6d1130792ab37a95b014550 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9213 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676607Reviewed-by: Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#62364}
-
Nico Hartmann authored
This CL introduces the necessary infrastructure to generate speculative BigInt operations in case of BigInt feedback. In particular, the JSAdd operator is lowered to a speculative call to the BigIntAdd builtin, with a deopt bailout in case of exceptions or violated assumptions. Bug: v8:9213 Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 Commit-Queue: Nico Hartmann <nicohartmann@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62362}
-
- 18 Apr, 2019 1 commit
-
-
Georg Neis authored
We see crashes in the wild that we suspect are caused by these changes. This is a manual revert because of conflicts. Revert "[turbofan] Fix incorrect CheckNonEmptyString lowering." This reverts commit b3b70118. Revert "[turbofan] Fix incorrect lowering of CheckNonEmptyString." This reverts commit 57582090. Revert "[turbofan] Significantly improve ConsString creation performance." This reverts commit d6a60a0e. Bug: v8:9147 Change-Id: I262c21e5406a9c4c8ad0e0f995582c5802f0fa1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571613Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60919}
-
- 03 Apr, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Includes both changing from compressed pointers and to compressed pointers. Also added tests to the representation changer test B Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng,v8_linux64_arm64_pointer_compression_rel_ng Bug: v8:8977 Change-Id: I8a13f6b7ec2208442aa354949173cc9061bce168 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533866Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#60587}
-
- 19 Mar, 2019 1 commit
-
-
Benedikt Meurer authored
This change significantly improves the performance of string concatenation in optimized code for the case where the resulting string is represented as a ConsString. On the relevant test cases we go from serializeNaive: 10762 ms. serializeClever: 7813 ms. serializeConcat: 10271 ms. to serializeNaive: 10278 ms. serializeClever: 5533 ms. serializeConcat: 10310 ms. which represents a 30% improvement on the "clever" benchmark, which tests specifically the ConsString creation performance. This was accomplished via a couple of different steps, which are briefly outlined here: 1. The empty_string gets its own map, so that we can easily recognize and handle it appropriately in the TurboFan type system. This allows us to express (and assert) that the inputs to NewConsString are non-empty strings, making sure that TurboFan no longer creates "crippled ConsStrings" with empty left or right hand sides. 2. Further split the existing String types in TurboFan to be able to distinguish between OneByte and TwoByte strings on the type system level. This allows us to avoid having to dynamically lookup the resulting ConsString map in case of ConsString creation (i.e. when we know that both input strings are OneByte strings or at least one of the input strings is TwoByte). 3. We also introduced more finegrained feedback for the Add bytecode in the interpreter, having it collect feedback about ConsStrings, specifically ConsOneByteString and ConsTwoByteString. This feedback can be used by TurboFan to only inline the relevant code for what was seen so far. This allows us to remove the Octane/Splay specific magic in JSTypedLowering to detect ConsString creation, and instead purely rely on the feedback of what was seen so far (also making it possible to change the semantics of NewConsString to be a low-level operator, which is only introduced in SimplifiedLowering by looking at the input types of StringConcat). 4. On top of the before mentioned type and interpreter changes we added new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and CheckNonEmptyTwoByteString, which perform the appropriate (dynamic) checks. There are several more improvements that are possible based on this, but since the change was already quite big, we decided not to put everything into the first change, but do some follow up tweaks to the type system, and builtin optimizations later. Tbr: mstarzinger@chromium.org Bug: v8:8834, v8:8931, v8:8939, v8:8951 Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Doc: https://bit.ly/fast-string-concatenation-in-javascript Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60318}
-
- 08 Jan, 2019 1 commit
-
-
Sigurd Schneider authored
This CL prevents redundancy elimination from widening types, which can cause problems if the input of a DeadValue (which has type None) is replaced by an equivalent node that does not have type None. This can happen because load elimination does not re-type nodes, for example. Bug: chromium:919340 Change-Id: I89e872412edbcdc610e70ae160cde56cd045006c Reviewed-on: https://chromium-review.googlesource.com/c/1397709Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58617}
-
- 29 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This introduces Word64 support for the CheckBounds operator, which now lowers to either CheckedUint32Bounds or CheckedUint64Bounds after the representation selection. The right hand side of CheckBounds can now be any positive safe integer on 64-bit architectures, whereas it remains Unsigned31 for 32-bit architectures. We only use the extended Word64 support when the right hand side is outside the Unsigned31 range, so for everything except DataViews this means that the performance should remain the same. The typing rule for the CheckBounds operator was updated to reflect this new behavior. The CheckBounds with a right hand side outside the Unsigned31 range will pass a new Signed64 feedback kind, which is handled with newly introduced CheckedFloat64ToInt64 and CheckedTaggedToInt64 operators in representation selection. The JSCallReducer lowering for DataView getType()/setType() methods was updated to not smi-check the [[ByteLength]] and [[ByteOffset]] anymore, but instead just use the raw uintptr_t values and operate on any value (for 64-bit architectures these fields can hold any positive safe integer, for 32-bit architectures it's limited to Unsigned31 range as before). This means that V8 can now handle huge DataViews fully, without falling off a performance cliff. This refactoring even gave us some performance improvements, on a simple micro-benchmark just exercising different DataView accesses we go from testDataViewGetUint8: 796 ms. testDataViewGetUint16: 997 ms. testDataViewGetInt32: 994 ms. testDataViewGetFloat64: 997 ms. to testDataViewGetUint8: 895 ms. testDataViewGetUint16: 889 ms. testDataViewGetInt32: 888 ms. testDataViewGetFloat64: 890 ms. meaning we lost around 10% on the single byte case, but gained 10% across the board for all the other element sizes. Design-Document: http://bit.ly/turbofan-word64 Bug: chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383 Change-Id: Ic9d1bf152e47802c04dcfd679372e5c85e4abc83 Reviewed-on: https://chromium-review.googlesource.com/c/1303732Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57095}
-
- 24 Oct, 2018 2 commits
-
-
Benedikt Meurer authored
This changes the ReceiverOrOddball feedback on JSStrictEqual to ReceiverOrNullOrUndefined feedback, which can also safely be consumed by JSEqual (we cannot generally accept any oddball here since booleans trigger implicit conversions, unfortunately). Thus we replace the previously introduced CheckReceiverOrOddball with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since we will no longer collect Oddball feedback separately. TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into a sequence like this: ``` left = CheckReceiverOrNullOrUndefined(left); right = CheckReceiverOrNullOrUndefined(right); result = if ObjectIsUndetectable(left) then ObjectIsUndetectable(right) else ReferenceEqual(left, right); ``` This significantly improves the peak performance of abstract equality with Receiver, Null or Undefined inputs. On the test case outlined in http://crbug.com/v8/8356 we go from naive: 2946 ms. tenary: 2134 ms. to naive: 2230 ms. tenary: 2250 ms. which corresponds to a 25% improvement on the abstract equality case. For regular code this will probably yield more performance, since we get rid of the JSEqual operator, which might have arbitrary side effects and thus blocks all kinds of TurboFan optimizations. The JSStrictEqual case is slightly slower now, since it has to rule out booleans as well (even though that's not strictly necessary, but consistency is key here). This way developers can safely use `a == b` instead of doing a dance like `a == null ? b == null : a === b` (which is what dart2js does right now) when both `a` and `b` are known to be Receiver, Null or Undefined. The abstract equality is not only faster to parse than the tenary, but also generates a shorter bytecode sequence. In the test case referenced in http://crbug.com/v8/8356 the bytecode for `naive` is ``` StackCheck Ldar a1 TestEqual a0, [0] JumpIfFalse [5] LdaSmi [1] Return LdaSmi [2] Return ``` which is 14 bytes, whereas the `tenary` function generates ``` StackCheck Ldar a0 TestUndetectable JumpIfFalse [7] Ldar a1 TestUndetectable Jump [7] Ldar a1 TestEqualStrict a0, [0] JumpIfToBooleanFalse [5] LdaSmi [1] Return LdaSmi [2] Return ``` which is 24 bytes. So the `naive` version is 40% smaller and requires fewer bytecode dispatches. Bug: chromium:898455, v8:8356 Change-Id: If3961b2518b4438700706b3bd6071d546305e233 Reviewed-on: https://chromium-review.googlesource.com/c/1297315Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56948}
-
Benedikt Meurer authored
This CL introduces proper Oddball and ReceiverOrOddball states for the CompareOperationFeedback, and updates the StrictEqual IC to collect this feedback as well. Previously it would not collect Oddball feedback, not even in the sense of NumberOrOddball, since that's not usable for the SpeculativeNumberEqual. The new feedback is handled via newly introduced CheckReceiverOrOddball and CheckOddball operators in TurboFan, introduced by JSTypedLowering. Just like with the Receiver feedback, it's enough to check one side and do a ReferenceEqual afterwards, since strict equal can only yield true if both sides refer to the same instance. This improves the benchmark mentioned in http://crbug.com/v8/8356 from naive: 2950 ms. tenary: 2456 ms. to around naive: 2996 ms. tenary: 2192 ms. which corresponds to a roughly 10% improvement in the case for the tenary pattern, which is currently used by dart2js. In real world scenarios this will probably help even more, since TurboFan is able to optimize across the strict equality, i.e. there's no longer a stub call forcibly spilling all registers that are live across the call. This new feedback will be used as a basis for the JSEqual support for ReceiverOrOddball, which will allow dart2js switching to the shorter a==b form, at the same peak performance. Bug: v8:8356 Change-Id: Iafbf5d64fcc9312f9e575b54c32c631ce9b572b2 Reviewed-on: https://chromium-review.googlesource.com/c/1297309Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56925}
-
- 07 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
As identified in the web-tooling-benchmark, there are specific code patterns involving array indexed property accesses and subsequent comparisons of those indices that lead to repeated Smi checks in the optimized code, which in turn leads to high register pressure and generally bad register allocation. An example of this pattern is code like this: ```js function f(a, n) { const i = a[n]; if (n >= 1) return i; } ``` The `a[n]` property access introduces a CheckBounds on `n`, which later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`, however the `n >= 1` comparison has collected `SignedSmall` feedback and so it introduces a `CheckedTaggedToTaggedSigned` operation. This second Smi check is redundant and cannot easily be combined with the earlier tagged->int32 conversion, since that also deals with heap numbers and even truncates -0 to 0. So we teach the RedundancyElimination to look at the inputs of these speculative number comparisons and if there's a leading bounds check on either of these inputs, we change the input to the result of the bounds check. This avoids the redundant Smi checks later and generally allows the SimplifiedLowering to do a significantly better job on the number comparisons. We only do this in case of SignedSmall feedback and only for inputs that are not already known to be in UnsignedSmall range, to avoid doing too many (unnecessary) expensive lookups during RedundancyElimination. All of this is safe despite the fact that CheckBounds truncates -0 to 0, since the regular number comparisons in JavaScript identify 0 and -0 (unlike Object.is()). This also adds appropriate tests, especially for the interesting cases where -0 is used only after the code was optimized. Bug: v8:6936, v8:7094 Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07 Reviewed-on: https://chromium-review.googlesource.com/c/1246181Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56428}
-
- 20 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
Remove the NumberConstant right hand side limitation for the speculative number operation optimization, and extend the logic to also deal with SpeculativeToNumber, which is common when dealing with postfix increment and array operations. Also add appropriate tests for all the relevant cases, specifically we mjsunit tests to increase the general coverage for the various cases here (in addition to dedicated unittests). Bug: v8:8015 Change-Id: I8c92f98490c63b07eb19686efd404322979e57c4 Reviewed-on: https://chromium-review.googlesource.com/1235919Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56072}
-
- 19 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
Make the RedundancyElimination handle all simplified operators that are listed in the SIMPLIFIED_CHECKED_OP_LIST, and fix a couple of bugs and oversights in the code. This also adds a lot of test coverage for all the cases that we care about in RedundancyElimination (with respect to Check/Checked simplified operators). Bug: v8:8015 Change-Id: I57d29113389841b09abcd013313bf5dd1c67735f Reviewed-on: https://chromium-review.googlesource.com/1233655Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56032}
-
- 17 Sep, 2018 1 commit
-
-
Florian Sattler authored
Fixing clang-tidy warning. Bug: v8:8015 Change-Id: I7d885f0e2ba3cdf97de190166dc4cdd24dc0c11e Reviewed-on: https://chromium-review.googlesource.com/1224091 Commit-Queue: Florian Sattler <sattlerf@google.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#55956}
-
- 07 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
This replaces the previous CheckStringAdd operator which deopts in case the combined length overflows with a dedicated pure StringConcat operator. This operator is similar to NewConsString in that it takes the resulting length plus the two input strings. The operator relies on the length being checked explicitly by the surrounding code instead of baking the check into the operator itself. This way TurboFan can eliminate redundant/unnecessary StringConcat operations, since they are pure now. This also unifies the treatment of string addition in JSTypedLowering, and generalizes the StringLength constant-folding to apply to more cases not just the JSAdd cases inside JSTypedLowering. Bug: v8:7902, v8:8015 Change-Id: I987ec39815a9464fd5fd9c4f7b26b709f94f2b3f Reviewed-on: https://chromium-review.googlesource.com/1213205Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55725}
-
- 29 Aug, 2018 1 commit
-
-
Maya Lekova authored
The new node is introduced for literal string addition and calling String.prototype.concat in the typed lowering phase. It later might get optimized away during redundancy elimination, keeping the performance of already existing benchmarks with string addition. In case the operation is about to throw (due to too long string being constructed) we just deoptimize, reusing the interpreter logic for creating the error. Modify relevant mjsunit and unit tests for string concatenation. Bug: v8:7902 Change-Id: Ie97d39534df4480fa8d4fe3ba276d02ed5e750e3 Reviewed-on: https://chromium-review.googlesource.com/1193342 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#55482}
-
- 30 Apr, 2018 1 commit
-
-
Jaroslav Sevcik authored
This removes Type::operator-> which was used to split the change that removed undefined misuse of Type* to represent integers. Bug: v8:3770 Change-Id: I9a5bce5ccdc75461a7b939b4070cb58fe6040d99 Reviewed-on: https://chromium-review.googlesource.com/1033736Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52878}
-
- 16 Mar, 2018 1 commit
-
-
Benedikt Meurer authored
A value of type OtherSeqString can change its type to OtherNonSeqString via inplace internalization (and redirection via a ThinString). This can lead to out of bounds memory accesses and generally correctness bugs, as seen with crbug.com/822284. This change might affect performance in some cases, and we'll need to evaluate whether it's worth spending cycles on adding another mechanism that leverages the sequential string information in a safe way on a case by case basis. Bug: chromium:822284 Change-Id: I0de77ec089a774236555f38c365f7548f454edfe Reviewed-on: https://chromium-review.googlesource.com/966021Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#51975}
-
- 11 Jan, 2018 1 commit
-
-
Georg Neis authored
Also sort some lists to improve readability. Bug: Change-Id: I296d1706e7c568c325732e9c57622bc4de571d62 Reviewed-on: https://chromium-review.googlesource.com/859240Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50517}
-
- 29 Dec, 2017 1 commit
-
-
Sigurd Schneider authored
Update notion of compatibility used in redundancy elimination to determine whether one check subsumes another check to ignore the feedback on the operator. Bug: v8:7127 Change-Id: I77ab8a64adcd2b36ee7eafbe6cc148ddbc430b11 Reviewed-on: https://chromium-review.googlesource.com/839441 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#50318}
-
- 14 Dec, 2017 2 commits
-
-
Sigurd Schneider authored
Bug: v8:7127, v8:7204 Change-Id: I923658dd9142d658f1155015f5ee02526d280e2a Reviewed-on: https://chromium-review.googlesource.com/824171 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#50101}
-
Sigurd Schneider authored
Add support for disallowing speculation upon deoptimize from a CheckBound node, and use this in the case of array builtins in js-call-reducer to prevent deoptimization loops. Bug: v8:7127 Change-Id: I04cf655b10178d2938d2f0ee6b336601fab6463b Reviewed-on: https://chromium-review.googlesource.com/822195 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#50097}
-
- 30 Aug, 2017 1 commit
-
-
Jaroslav Sevcik authored
Bug: chromium:760434 Change-Id: I95bcf33f334349de0a81f574ba64128b8e1b2ebd Reviewed-on: https://chromium-review.googlesource.com/643192 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47723}
-
- 19 Jul, 2017 1 commit
-
-
Ross McIlroy authored
There remained a few of regressions and we didn't see any significant improvement in the real world with this turned on. This CL reverts all the StringConcat bytecode work which landed. BUG=v8:6243 Change-Id: I832eb72e880ad41411dbec8fe29f71ef0f2025c8 Reviewed-on: https://chromium-review.googlesource.com/575130 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46769}
-
- 08 Jun, 2017 2 commits
-
-
Ross McIlroy authored
Add the ability for the typer to track whether a string could be the empty string. This is needed for typed lowering of JSStringConcat since we can't create cons string chain with the empty string in arbitrary positions. The ToPrimitiveToString bytecode handler is modified to collect feedback on whether it has ever seen the empty string, which is used by SpeculativeToPrimitiveToString to ensure that the output is non-empty (or depot) which will subsiquently be used to enable inline cons-string creation for the JSStringConcat operator in typed lowering in a subsiquent CL. BUG=v8:6243 Change-Id: I41b99b59798993f756aada8cff90fb137d65ea52 Reviewed-on: https://chromium-review.googlesource.com/522122 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#45786}
-
Mythri authored
ThrowIfHole bytecodes were handled by introducing deopt points to check for a hole. To avoid deopt loops a hole check protector was used to generate control flow if there was a deopt due to a hole. However, the normal control flow version should be as fast as the deopt version in general. The deopt version could potentially consume less compile time but it may not be worth the complexity added. Hence simplifying it to only construct the control flow. Bug: v8:6383 Change-Id: Icace11f7a6e21e64e1cebd104496e3f559bc85f7 Reviewed-on: https://chromium-review.googlesource.com/525573Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#45783}
-
- 06 Jun, 2017 1 commit
-
-
Mythri authored
Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole / ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks. In the bytecode-graph builder they are handled by introducing a deopt point instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant bytecodes are removed since they are no longer required. Bug: v8:4280, v8:6383 Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1 Reviewed-on: https://chromium-review.googlesource.com/509613 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45720}
-
- 29 May, 2017 1 commit
-
-
Peter Marshall authored
Bug: v8:6391 Change-Id: If63078c756d9cfb00e515fae005755c4ed8b12f7 Reviewed-on: https://chromium-review.googlesource.com/512803Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#45549}
-
- 18 Jan, 2017 1 commit
-
-
bmeurer authored
Collect Receiver feedback for abstract/strict equality in Ignition and use it in TurboFan to optimize JSEqual and JSStrictEqual operations to pointer equality instead of having to call Equal/StrictEqual builtins. R=jarin@chromium.org BUG=v8:5267,v8:5400 Review-Url: https://codereview.chromium.org/2639883002 Cr-Commit-Position: refs/heads/master@{#42435}
-