- 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}
-
- 08 Feb, 2019 1 commit
-
-
Jaroslav Sevcik authored
Instead of eliminating bounds checks based on types, we introduce an aborting bounds check that crashes rather than deopts. Bug: v8:8806 Change-Id: Icbd9c4554b6ad20fe4135b8622590093679dac3f Reviewed-on: https://chromium-review.googlesource.com/c/1460461 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59467}
-
- 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}
-
- 07 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This reverts commit 4fd92b25. Reason for revert: Significant tankage on the no-mitigations bots (bad timing on the regular bots) Original change's description: > [turbofan] Do not consume SignedSmall feedback in TurboFan anymore. > > This changes TurboFan to treat SignedSmall feedback similar to Signed32 > feedback for binary and compare operations, in order to simplify and > unify the machinery. > > This is an experiment. If this turns out to tank performance, we will > need to revisit and ideally revert this change. > > Bug: v8:7094 > Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1 > Reviewed-on: https://chromium-review.googlesource.com/c/1261442 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56411} TBR=jarin@chromium.org,bmeurer@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7094 Change-Id: I9fff3b40e6dc0ceb7611b55e1ca9940089470404 Reviewed-on: https://chromium-review.googlesource.com/c/1267175Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56427}
-
- 05 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This changes TurboFan to treat SignedSmall feedback similar to Signed32 feedback for binary and compare operations, in order to simplify and unify the machinery. This is an experiment. If this turns out to tank performance, we will need to revisit and ideally revert this change. Bug: v8:7094 Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1 Reviewed-on: https://chromium-review.googlesource.com/c/1261442Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56411}
-
- 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 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}
-
- 24 Aug, 2018 1 commit
-
-
Florian Sattler authored
This reduces the enum size to only take up one byte, hence decreasing class size. Bug: v8:7926 Change-Id: Ie50cfcd48541e44394814f375fd72f2b65722fdf Reviewed-on: https://chromium-review.googlesource.com/1186582 Commit-Queue: Florian Sattler <sattlerf@google.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#55378}
-
- 22 Aug, 2018 1 commit
-
-
Benedikt Meurer authored
This adds the missing support for HOLEY_DOUBLE_ELEMENTS to both `Array#find()` and `Array#findIndex()`. The implementation just deopts whenever it hits a double hole. In order to prevent deoptimization loops we add feedback to the CheckFloat64Hole operator, which also addresses the TODO in the `%ArrayIteratorPrototype%.next()` lowering. This provides a speed-up of up to 8x in microbenchmarks when using `Array#find()` or `Array#findIndex()` on HOLEY_DOUBLE_ELEMENTS arrays. Bug: chromium:791045, v8:1956, v8:6587, v8:7165, v8:8015 Change-Id: I1be22d3fcba56c676a81dc31a9042f8123ef3a55 Reviewed-on: https://chromium-review.googlesource.com/1183906Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55321}
-
- 23 Jul, 2018 1 commit
-
-
Stephan Herhut authored
This moves the static handle() helper function to handles-inl.h as it ultimately depends on handles-inl.h anyway. To make this possible, also move some other code to -inl.h files and split up some header files into a -inl.h part. Bug: v8:7490 Change-Id: I0f68e0728ba082b87ffa911aaf205d9b1523d2c9 Reviewed-on: https://chromium-review.googlesource.com/1146723Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Stephan Herhut <herhut@chromium.org> Cr-Commit-Position: refs/heads/master@{#54617}
-
- 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}
-
- 29 May, 2018 1 commit
-
-
Sigurd Schneider authored
Bug: v8:7779 Change-Id: I97d7a46039d9063e4169fa215f7f6857c80eb3b9 Reviewed-on: https://chromium-review.googlesource.com/1076087Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#53404}
-
- 16 May, 2018 1 commit
-
-
Marja Hölttä authored
BUG=v8:7490 Change-Id: I53888e391a0ad25407e59431b2fffbd7cacf5273 Reviewed-on: https://chromium-review.googlesource.com/1060060 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53205}
-
- 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}
-
- 28 Apr, 2018 1 commit
-
-
Jaroslav Sevcik authored
This is part of the effort to decrease the amount of undefined behavior. that v8 relies on. The main change here is to represent types with class Type rather than with pointer Type*. To make the CL smaller, I used an operator overload hack to separate the change from `->` to `.`. I am working on a CL that will remove the operator and change all those arrows to dots. Bug: v8:3770 Change-Id: I71a197cb739a1467937bc95c2a757fab0469aa22 Reviewed-on: https://chromium-review.googlesource.com/1032551 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#52872}
-
- 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}
-
- 06 Apr, 2018 1 commit
-
-
Clemens Hammacher authored
Replace all uses with V8_WARN_UNUSED_RESULT. WARN_UNUSED_RESULT was defined in src/base/compiler-specific.h, which includes include/v8config.h, which already defined V8_WARN_UNUSED_RESULT. R=mstarzinger@chromium.org Bug: v8:7570 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I662072294605036ca5aa0c8fdaa0218ac5d95f23 Reviewed-on: https://chromium-review.googlesource.com/998893Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52457}
-
- 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 2 commits
-
-
Sigurd Schneider authored
Bug: v8:7570, v8:7517 Change-Id: Ia62a9afeec0d0df1596198deec6165a3f02edeaa Reviewed-on: https://chromium-review.googlesource.com/973606Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#52120}
-
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}
-
- 20 Mar, 2018 1 commit
-
-
Jaroslav Sevcik authored
This prevent forgotten field initializations. Bug: v8:5267 Change-Id: Iaef5f79af360e2400b29afe878f80870c8a64e71 Reviewed-on: https://chromium-review.googlesource.com/970241 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52049}
-
- 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}
-
- 12 Mar, 2018 1 commit
-
-
Sigurd Schneider authored
This CL now uses StringCharCodeAt + StringFromCharCode to replace StringCharAt. Optimizations are easier to implement if we have both operators; however, if this tanks performance a lot we have to revert. R=bmeurer@chromium.org Bug: v8:7531 Change-Id: I75590cc8b8db57715bc2de9f5b98d0878d62a394 Reviewed-on: https://chromium-review.googlesource.com/956134 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51877}
-
- 05 Mar, 2018 1 commit
-
-
Sigurd Schneider authored
Bug: v8:7517, v8:7310 Change-Id: I438bc933d51062bfbb9a419be9c5b67032707fdb Reviewed-on: https://chromium-review.googlesource.com/946090 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51726}
-
- 23 Feb, 2018 1 commit
-
-
Sigurd Schneider authored
Adding the StringSubstring simplified operator is a precursor to improve inlining of String.p.{substr,substring,slice}. This also contains a drive-by renaming to normalize different spellings of 'Substring'. Bug: v8:7250, v8:7340 Change-Id: I89e0fbafeab80f5d2f3ef348a5303d32c0abfe0a Reviewed-on: https://chromium-review.googlesource.com/919084 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51522}
-
- 15 Feb, 2018 1 commit
-
-
Toon Verwaest authored
instance_class_name takes up space unnecessarily, and %_ClassOf and class_name implement [[Class]] which isn't part of ES2015+ anymore. Bug: Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I3a73f732ad83a616817fde9992f4e4d584638fa8 Reviewed-on: https://chromium-review.googlesource.com/776683Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#51309}
-
- 08 Feb, 2018 1 commit
-
-
Sigurd Schneider authored
Bug: v8:7250 Change-Id: If4c9d0b32939a06993d3ffb39ac4b19edbad422f Reviewed-on: https://chromium-review.googlesource.com/906731Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#51184}
-