- 24 Oct, 2019 1 commit
-
-
Ross McIlroy authored
This rearranges the TurboProp pipeline to avoid the need for a second schedule of the graph. To do this, it moves the final schedule creation before effect-control-linearization (which used a temporary schedule previously, and with TurboFan). It then enables the block updater in the graph assembler for effect control linearization and does select and memory lowering in a new ScheduledMachineLowering phase to maintain this existing schedule during these lowering passes. BUG=v8:9684 Change-Id: I6a7790b010f8b152dd01d85aa95ee5d4f99087a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847351 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64537}
-
- 28 May, 2019 1 commit
-
-
Santiago Aboy Solanes authored
The DecompressionElimination reducer can handle that case with the comparison of Decompress vs HeapConstant. There is no need to do extra work. Reverts parts of https://chromium-review.googlesource.com/c/v8/v8/+/1518182. The rest of that CL was reverted in a previous CL where the AccessBuilders were updated. 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:8977, v8:7703 Change-Id: I871577e49f9ccd95864af54bdd61884d34b7f223 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628792Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#61883}
-
- 23 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I0023200c54fa6499ae4e2cf5e4c89407cc35f187 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624218Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61762}
-
- 10 May, 2019 1 commit
-
-
Georg Neis authored
... by moving the EffectControlLinearizer class into the .cc file and only exposing a single function in the header. Change-Id: I63dc3edd9de7df60041f0687d920996e308e0d4e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605739 Commit-Queue: Georg Neis <neis@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61413}
-
- 09 May, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Going back on https://chromium-review.googlesource.com/c/v8/v8/+/1480382 since now 'tagged' means 'full tagged' again. I am keeping the access builder since that seems useful to have (as opposed to building the access builder in the implementation). 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:8977, v8:7703, v8:9206 Change-Id: I7c38b090190aa1c3e91c5ab9f729588aeae2dc1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594439 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61371}
-
- 08 May, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Going back on https://chromium-review.googlesource.com/c/v8/v8/+/1445978 since now 'tagged' means 'full tagged' again. 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:8977, v8:7703 Change-Id: I3e39d631cc720a28577dad482dadfcc8332b6b18 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593301 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#61339}
-
- 18 Apr, 2019 2 commits
-
-
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}
-
Jaroslav Sevcik authored
This uses the same comparison as the ICs to make sure that ICs learn after deoptimization (see https://chromium-review.googlesource.com/c/v8/v8/+/1561319 for the IC fix). Bug: v8:9139 Change-Id: I67a361d85ee0c8a4ad4a6abc2d33ac4ca5fa22bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1569438 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60917}
-
- 11 Apr, 2019 1 commit
-
-
Jaroslav Sevcik authored
Bug: v8:9113 Change-Id: I413d9df34f0bdea9c30db33ad79891218e229341 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564053Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#60776}
-
- 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 2 commits
-
-
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}
-
Mike Stanton authored
If pointer compression is on, it makes sense to embed the map as a 32-bit constant, for direct comparison. No need to uncompress the receiver map. Bug: v8:8982 Change-Id: I285ca4d5b49b26536873776d298e18bcbf84b23e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518182Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#60313}
-
- 22 Feb, 2019 1 commit
-
-
Santiago Aboy Solanes authored
This now makes it so TurboFan now uses full pointer loads for arguments values located on stack. Bug: v8:8876, v8:7703 Change-Id: Ib82d6f3b0f4c8d33669c7f86ce803381d210c019 Reviewed-on: https://chromium-review.googlesource.com/c/1480382Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#59798}
-
- 31 Jan, 2019 1 commit
-
-
Sigurd Schneider authored
These allow to write a tagged uncompressed pointer even if pointer compression is enabled. This is the least intrusive option; once TurboFan supports pointer compression better, this CL likely needs to be revised. Bug: v8:8183 Change-Id: I56451c364b8620f687d8b9deb9553099ba95b928 Reviewed-on: https://chromium-review.googlesource.com/c/1445978 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59247}
-
- 09 Nov, 2018 1 commit
-
-
Benedikt Meurer authored
Previously we'd check `x` for -0 by testing `(1.0 / x) == -Infinity`, but this will yield the wrong results when `x` is a subnormal, i.e. really close to 0. In CSA we already perform bit checks to test for -0, so teach TurboFan to do the same for comparisons to -0 (via `Object.is`). We introduce a new NumberIsMinusZero simplified operator to handle the case where SimplifiedLowering already knows that the input is a number. Bug: chromium:903043, v8:6882 Change-Id: I0cb7c568029b461a92fc183104d5f359b4bfe7f4 Reviewed-on: https://chromium-review.googlesource.com/c/1328802 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#57382}
-
- 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}
-
- 20 Sep, 2018 1 commit
-
-
Yang Guo authored
We now clearly differentiate between: - unseeded hash for 32-bit integers - unseeded hash for 64-bit integers - seeded hash for 32-bit integers - seeded hash for strings R=bmeurer@chromium.org Bug: chromium:680662 Change-Id: I7459958c4158ee3501c962943dff8f33258bb5ce Reviewed-on: https://chromium-review.googlesource.com/1235973 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56068}
-
- 17 Sep, 2018 2 commits
-
-
Benedikt Meurer authored
Cleanup the JSArrayBuffer bit fields to use the proper object macros that are now otherwise used consistently across the code base. Also change TurboFan to consistently bailout when it sees an array buffer that was previously neutered, so that the generic path / builtins are again the chokepoints for the spec violations (the fact that we don't always raise exceptions when we see a neutered array buffer), except for the ArrayBufferView accessor inlining in the JSCallReducer, where we still turn the values into zero (because we don't have access to a CALL_IC speculation guard in the common case). This also removes the ArrayBufferWasNeutered simplified operator, and does regular LoadField + Number bitwise operations instead, which is good enough and allows us to get rid of a lot of unnecessary complexity. Bug: v8:4153, v8:7881, v8:8015, v8:8171, v8:8178 Change-Id: I4ce79ece762c632e6318f2ab7bcc6b2f82383947 Reviewed-on: https://chromium-review.googlesource.com/1226887Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55958}
-
Benedikt Meurer authored
This change introduces the necessary conversion operators to convert from Word64 to other representations (Tagged, Word32, Float64, etc.), and plugs in the Word64 representation for NumberAdd/NumberSubtract, such that TurboFan will go to Int64Add/Sub on 64-bit architectures when the inputs and the output of the operation is in safe integer range. This includes the necessary changes to the Deoptimizer to be able to rematerialize Int64 values as Smi/HeapNumber when going back to Ignition later. This change might affect performance, although measurements indicate that there should be no noticable performance impact. The goal is to have TurboFan support Word64 representation to a degree that changing the TypedArray length to an uint64_t (for 64-bit archs) becomes viable and doesn't have any negative performance implications. Independent of that we might get performance improvements in other areas such as for crypto code later. Bug: v8:4153, v8:7881, v8:8171, v8:8178 Design-Document: bit.ly/turbofan-word64 Change-Id: I29d56e2a31c1bae61d04a89d29ea73f21fd49c59 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel Reviewed-on: https://chromium-review.googlesource.com/1225709 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#55937}
-
- 14 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
This adds support to TurboFan's representation selection for the Word64 representation, and makes use of that to handle indices for memory access and allocation instructions (i.e. LoadElement, StoreElement, Allocate, etc.). These instructions had previously used Word32 as representation for the indices / sizes, and then internally converted it to the correct representation (aka Word64 on 64-bit architectures) later on, but that was kind of brittle, and sometimes led to weird generated code. The change thus only adds support to convert integer values in the safe integer range from all kinds of representations to Word64 (on 64-bit architectures). We don't yet handle the opposite direction and none of the representation selection heuristics for the numeric operations were changed so far. This will be done in follow-up CLs. This CL itself is supposed to be neutral wrt. functionality, and only serves as a starting point, and a cleanup for the (weird) implicit Word64 index/size handling. Bug: v8:7881, v8:8015, v8:8171 Design-Document: http://bit.ly/turbofan-word64 Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel Reviewed-on: https://chromium-review.googlesource.com/1224932 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#55886}
-
- 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}
-
- 20 Aug, 2018 1 commit
-
-
Benedikt Meurer authored
The CheckedInt32Mod lowering in the EffectControlLinearizer wasn't playing well with subsequent optimizations in the MachineOperatorReducer especially due to the use of Int32Mod, which introduces another (floating) diamond in the MachineOperatorReducer. Switching to Uint32Mod and explicit sign handling fixes the problem, plus we also do the mask trick in the case where the left hand side is negative now. With this change the performance on the benchmark mentioned in the bug report goes from console.timeEnd: binary, 1872.346000 console.timeEnd: modulo, 5967.464000 console.timeEnd: binary, 6006.789000 console.timeEnd: modulo, 6293.496000 console.timeEnd: binary, 5969.264000 console.timeEnd: modulo, 6291.874000 to console.timeEnd: binary, 1876.464000 console.timeEnd: modulo, 5846.643000 console.timeEnd: binary, 5962.545000 console.timeEnd: modulo, 5972.639000 console.timeEnd: binary, 5958.221000 console.timeEnd: modulo, 5973.171000 so even the peak performance of the modulus is now mostly the same as the binary bitwise and. Bug: v8:8069 Change-Id: Iaf3828fc0f6c53352367e8bf6c42534f8b13bfb3 Reviewed-on: https://chromium-review.googlesource.com/1180971Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55211}
-
- 14 Aug, 2018 2 commits
-
-
Benedikt Meurer authored
This adds support for unaligned load/store access to the DataView backing store and uses byteswap operations to fix up the endianess when necessary. This changes the Word32ReverseBytes operator to be a required operator and adds the missing support on the Intel and ARM platforms (on 64-bit platforms the Word64ReverseBytes operator is also mandatory now). This further improves the performance on the dataviewperf.js test mentioned in the tracking bug by up to 40%, and at the same time reduces the code complexity in the EffectControlLinearizer. Bug: chromium:225811 Change-Id: I7c1ec826faf46a144a5a9068f8f815a5fd040997 Reviewed-on: https://chromium-review.googlesource.com/1174252Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55111}
-
Leszek Swirski authored
This reverts commit c46915b9. Reason for revert: Disasm failures https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/21727 Original change's description: > [turbofan] Further optimize DataView accesses. > > This adds support for unaligned load/store access to the DataView > backing store and uses byteswap operations to fix up the endianess > when necessary. This changes the Word32ReverseBytes operator to be > a required operator and adds the missing support on the Intel and > ARM platforms (on 64-bit platforms the Word64ReverseBytes operator > is also mandatory now). > > This further improves the performance on the dataviewperf.js test > mentioned in the tracking bug by up to 40%, and at the same time > reduces the code complexity in the EffectControlLinearizer. > > Bug: chromium:225811 > Change-Id: I296170b828c2ccc1c317ed37840b564aa14cdec2 > Reviewed-on: https://chromium-review.googlesource.com/1172777 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#55099} TBR=sigurds@chromium.org,bmeurer@chromium.org Change-Id: If7a62e3a1a4ad26823fcbd2ab6eb4c053ad11c49 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:225811 Reviewed-on: https://chromium-review.googlesource.com/1174171Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#55107}
-
- 13 Aug, 2018 1 commit
-
-
Benedikt Meurer authored
This adds support for unaligned load/store access to the DataView backing store and uses byteswap operations to fix up the endianess when necessary. This changes the Word32ReverseBytes operator to be a required operator and adds the missing support on the Intel and ARM platforms (on 64-bit platforms the Word64ReverseBytes operator is also mandatory now). This further improves the performance on the dataviewperf.js test mentioned in the tracking bug by up to 40%, and at the same time reduces the code complexity in the EffectControlLinearizer. Bug: chromium:225811 Change-Id: I296170b828c2ccc1c317ed37840b564aa14cdec2 Reviewed-on: https://chromium-review.googlesource.com/1172777 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#55099}
-
- 09 Jul, 2018 1 commit
-
-
Théotime Grohens authored
This CL completes the implementation of DataView prototype methods in TurboFan, by implementing the Uint8, Int8, Uint16, Int16, Uint32, Int32, Float32 and Float64 setters. DataView performance is now ahead of the equivalent TypedArray wrapper, and is now expected to at least match TypedArray performance in the general case as well. This CL also adds a test file in the compiler directory, to make sure that the setters actually behave correctly. Change-Id: I4ad4341c6b9b9d461348b62216f37a73abe321e8 Reviewed-on: https://chromium-review.googlesource.com/1128867Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#54331}
-
- 04 Jul, 2018 1 commit
-
-
Théotime Grohens authored
This CL creates a new Operator called LoadDataViewElement, similar to LoadTypedArray, for DataView getters. This operator will be used as a wrapper around all the computations that DataViews need to do when loading values, due to the endianness parameter of DataView loads. Change-Id: Ie67d63c9669142e539a5c8d7ae82dc1018ce5858 Reviewed-on: https://chromium-review.googlesource.com/1125928 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#54217}
-
- 18 May, 2018 1 commit
-
-
Sigurd Schneider authored
This also includes the precise reducer name. Currently the information is available in the node tooltip in turbolizer. The new shortcut 's' in the graph view selects the nodes the currently selected nodes were created from. Bug: v8:7327 Change-Id: I7ca7327d0cfa112972e3567df6e4a223c8eff3c0 Reviewed-on: https://chromium-review.googlesource.com/1064059 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53258}
-
- 30 Apr, 2018 1 commit
-
-
Jaroslav Sevcik authored
The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
-
- 25 Apr, 2018 1 commit
-
-
Sigurd Schneider authored
This CL also introduces an effect dependent simplified operator DateNow and associated lowerings. Bug: v8:7340, v8:7250 Change-Id: Icd4a8c3c45a8dbe7ef490fc3ee68c0c68bbed011 Reviewed-on: https://chromium-review.googlesource.com/1024836 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52782}
-
- 23 Apr, 2018 1 commit
-
-
Sigurd Schneider authored
This CL also adds the simplified operator NumberIsNaN. Bug: v8:7340, v8:7250 Change-Id: Ifa44cf59b30ee700f7df61f8d58782a43fd0f3c5 Reviewed-on: https://chromium-review.googlesource.com/1023391Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#52726}
-
- 23 Mar, 2018 2 commits
-
-
Sigurd Schneider authored
Also add a new fast-path for String.fromCodePoint. R=neis@chromium.org Bug: v8:7570, v8:7340 Change-Id: I6cd6e6fc98943588ecd646f24fcda043d4033ab0 Reviewed-on: https://chromium-review.googlesource.com/978244Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#52183}
-
Sigurd Schneider authored
This CL also cleans up some related naming in typed-optimization. R=neis@chromium.org Bug: v8:7531, v8:7570 Change-Id: If80e0e9642aaf6c58b164db2e1e0632cd5b0d051 Reviewed-on: https://chromium-review.googlesource.com/978066 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#52182}
-
- 21 Mar, 2018 1 commit
-
-
Sigurd Schneider authored
This also introduces two new simplified operators, ObjectIsSafeInteger and NumberIsSafeInteger. Bug: v8:7340, v8:7250 Change-Id: I9a3028d844e6614ed248a03fe24b431fb54938f0 Reviewed-on: https://chromium-review.googlesource.com/973221Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#52112}
-
- 16 Mar, 2018 3 commits
-
-
Sigurd Schneider authored
This also adds ObjectIsInteger and NumberIsInteger operators. Bug: v8:7340, v8:7250 Change-Id: I8067276d12c8532931f90e6397f8435362c2f9af Reviewed-on: https://chromium-review.googlesource.com/951602Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#51991}
-
Sigurd Schneider authored
This also introduces two new simplified operators, NumberIsFinite and ObjectIsFiniteNumber; the latter handles all values, and the former is a fast-path of the fast-path that is inserted by typed optimization if we know the input has Type::Number. Bug: v8:7340, v8:7250 Change-Id: I1b4812c01bf470bbff40fb3da6e11da543a22cd2 Reviewed-on: https://chromium-review.googlesource.com/951244 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51980}
-
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}
-