- 30 Oct, 2018 26 commits
-
-
Toon Verwaest authored
Change-Id: I233a3f6d8b19b945cfc3572d72237ec5619d8cbc Reviewed-on: https://chromium-review.googlesource.com/c/1307414Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57129}
-
Ivica Bogosavljevic authored
Port 15c31fe4 Change-Id: Ia611585f862196d97e701b5e15560044e42b1a12 Reviewed-on: https://chromium-review.googlesource.com/c/1306439Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com> Cr-Commit-Position: refs/heads/master@{#57128}
-
Clemens Hammacher authored
For memory limit checks, we should use the minimum of the --wasm-max-mem-pages flag and kV8MaxWasmMemoryPages. The former is a limit set by the user, the latter is the maximum we can handle internally. R=titzer@chromium.org Bug: chromium:898677 Change-Id: I3c549f4e90dd016b5d07475d9353f30134f76dcc Reviewed-on: https://chromium-review.googlesource.com/c/1305274 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57127}
-
Clemens Hammacher authored
This is a reland of bf3d7b9a Original change's description: > [wasm] Store compile errors in CompilationState > > We are currently storing compilation errors in the individual > compilation units and pass it to the ErrorThrower during finishing. > This CL changes that to store errors on the CompilationState directly. > From there, it is propagated to the ErrorThrower in the compilation > state callback. > This removes more work from the finisher task and slims down the > WasmCompilationUnits. > > R=mstarzinger@chromium.org > > Bug: v8:8343, v8:7921 > Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9 > Reviewed-on: https://chromium-review.googlesource.com/c/1303720 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57091} Bug: v8:8343, v8:7921 Change-Id: Iaa5c89d224cb2bcfca2d12eba305413a9ad95618 Reviewed-on: https://chromium-review.googlesource.com/c/1304547 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57126}
-
Hai Dang authored
BinaryNumberOpTyper was not monotonic: if one input changes from Number to Numeric, while the other input stays BigInt, the result would change from Number to BigInt. We have some fuzzing tests for monotonicity but unfortunately they never generated the inputs required for triggering this bug. We'll look into improving our tests. Bug: v8:8380 Change-Id: I7320d9ae4b89ad8798bf9e97cc272edba2162a77 Reviewed-on: https://chromium-review.googlesource.com/c/1307418 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#57125}
-
Jakob Gruber authored
Until this CL, CSA array allocation methods only handled arrays that could fit into new space. This behavior was preserved in a bunch of related builtins (e.g. Array.p.map), which completely bailed out to the slow path if larger allocations were required. This CL adds large object space handling to array allocation functions, which means that callers can use the more permissive kMaxFastArrayLength boundary instead of kInitialMaxFastElementsArray. Bug: chromium:890599 Change-Id: Idabb0ef232c2896cd453e2ae10b479bf24cbb1c1 Reviewed-on: https://chromium-review.googlesource.com/c/1301483 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Michael Starzinger authored
R=jgruber@chromium.org Change-Id: Ic9ef3cd231c2180563c3520ab58895f2ccce5408 Reviewed-on: https://chromium-review.googlesource.com/c/1307421Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57123}
-
Toon Verwaest authored
Bug: v8:8363, v8:7926 Change-Id: I60df70bcd1bc12b0cffe760532d92fa3e1fe7da2 Reviewed-on: https://chromium-review.googlesource.com/c/1307420Reviewed-by:
-
Stephan Herhut authored
The register allocator uses std::find to search for an element to be removed from the active/inactive queues repeatedly. As we already know the exact position of the element to remove, it is better to use an iterator right away. Change-Id: I2cd318a5960113d18b3749b2010f8028fe66158d Reviewed-on: https://chromium-review.googlesource.com/c/1304542 Commit-Queue: Stephan Herhut <herhut@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Michael Achenbach authored
NOTRY=true TBR=sergiyb@chromium.org Change-Id: I3751c64f86855d260e4fccd2f86e8958b7a8d9b3 Reviewed-on: https://chromium-review.googlesource.com/c/1307413Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#57120}
-
Michael Starzinger authored
This merges all control edges that are known to unconditionally throw directly into the graph end node. This applies to the "Throw" as well as the "Rethrow" operation, and reduces their code size. R=clemensh@chromium.org BUG=v8:8091 Change-Id: Idd4918ab084bcc697d5798d512ccc695ca943b00 Reviewed-on: https://chromium-review.googlesource.com/c/1305273Reviewed-by:
-
Benedikt Meurer authored
Bug: v8:1956, v8:8238 Change-Id: I5efc9ab7171cd35a4fcf2074f76dc9c90d521cc7 Reviewed-on: https://chromium-review.googlesource.com/c/1306440 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Andreas Haas authored
This is the V8 side of the implementation. You can take a look at a prototype of the Chrome side changes in https://crrev.com/c/1273043. Chrome could also use V8's default implementation of the trap handler, see https://crrev.com/c/1290952. Bug: v8:6743 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I9bb3e717db17a4f30bbb8acfd80a1f6510d463ff Reviewed-on: https://chromium-review.googlesource.com/c/1283111 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#57117}
-
Toon Verwaest authored
Bug: chromium:900085, v8:8363, v8:7926 Change-Id: I033bd4d95cdd85eee635279357c3c5d3fbe912c8 Reviewed-on: https://chromium-review.googlesource.com/c/1306438Reviewed-by:
-
Marja Hölttä authored
These tests rely on dropping references to objects either explicitly ("o = null;") or implicitly ("o goes out of scope") and then doing gc. It's essential that we haven't already marked the WeakCell pointing to o and marked it alive before dropping the reference. BUG=v8:8179 Change-Id: Ie0b73f05c4baa937cf6f28325454ff9087a71a2c Reviewed-on: https://chromium-review.googlesource.com/c/1306437Reviewed-by: -
Peter Marshall authored
If a caller starts the sampling heap profiler and takes a snapshot, and then deletes the snapshot before the sampling has completed, a use-after-free will occur on the StringsStorage pointer. The same issue applies for StartTrackingHeapObjects which shares the same StringsStorage object. Bug: v8:8373 Change-Id: I5d69d60d3f9465f9dd3b3bef107c204e0fda0643 Reviewed-on: https://chromium-review.googlesource.com/c/1301477 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#57114}
-
Stephan Herhut authored
Turns out TryReuseSpillForPhi does more than reusing a spill slot for a phi (which is beneficial in general). It also decides whether a phi should start out to be allocated in a spill slot. The latter, of course, benefits from control flow knowledge. Hence, this change was detrimental in cases where a common input to a phi is only spilled on few control flow pathes. To fix, we need to disentangle spill-slot reuse and the decision whether a phi should start out spilled. I will look into this in a follow up change. This reverts commit b79cbd56. Change-Id: I228185bb1a4b320d3115ba7f1d921593480d8e7d Reviewed-on: https://chromium-review.googlesource.com/c/1304549Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Stephan Herhut <herhut@chromium.org> Cr-Commit-Position: refs/heads/master@{#57113}
-
Ivica Bogosavljevic authored
MIPS64 is a 64-bit platform and each user space process can address 2^42 bytes of memory. This fixes the current behavior when the address range was limited to 2^30, which is the default value taken for 32-bit platforms. Change-Id: I310e16631a4dfaf77416e278ddf4386f3e258cc3 Reviewed-on: https://chromium-review.googlesource.com/c/1304197Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com> Cr-Commit-Position: refs/heads/master@{#57112}
-
Sigurd Schneider authored
Change-Id: I6a220b6043da8f9c8c036c92e3f4da6ca7d801d4 Bug: v8:8344 Reviewed-on: https://chromium-review.googlesource.com/c/1306436Reviewed-by:
-
Benedikt Meurer authored
This adds appropriate LoopExit nodes for the JSCallReducer lowerings of the following higher order Array builtins: - Array.prototype.every() - Array.prototype.find() - Array.prototype.findIndex() - Array.prototype.some() Loop peeling allows TurboFan to make loop invariant operations in the callback passed to the higher order builtin fully redundant, and thus completely eliminate the loop invariant code from the subsequent loop iterations. This can have a huge performance impact, depending on what kind of code runs inside of the callback. For example, on the micro- benchmarks outlined in http://crbug.com/v8/8273 we go from forLoop: 364 ms. every: 443 ms. some: 432 ms. find: 522 ms. findIndex: 437 ms. to forLoop: 369 ms. every: 354 ms. some: 348 ms. find: 419 ms. findIndex: 360 ms. which is 20% improvement, and essentially brings the Array builtins (the appropriate ones Array#some() and Array#every() in this case) on par with the hand-written `for`-loop. Bug: v8:1956, v8:8273 Change-Id: I9d32736e5402807b4ac79cd5ad15ceacd1945681 Reviewed-on: https://chromium-review.googlesource.com/c/1305935Reviewed-by:
Daniel Clifford <danno@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57110}
-
Sigurd Schneider authored
Change-Id: Iba905f4c1f2e5aff70953bdfb0009b417a959a41 Bug: v8:8344 Reviewed-on: https://chromium-review.googlesource.com/c/1304548Reviewed-by:
-
Benedikt Meurer authored
Be more consistent for elements kinds and polymorphism in various Array builtins, which are only iterating over elements. Bug: v8:1956 Change-Id: I0c02a1b18d95e678e01b816aa36b259a3ba76170 Reviewed-on: https://chromium-review.googlesource.com/c/1306434Reviewed-by:
-
Sigurd Schneider authored
Change-Id: Ic0513662eed0bd47bbc8c2ecec8fadd6b62f58f5 Bug: v8:8344 Reviewed-on: https://chromium-review.googlesource.com/c/1304550Reviewed-by:
-
Igor Sheludko authored
and use Mixin pattern with linear inheritance instead. This will allow to customize the way the Isolate is created. Bug: v8:8238 Change-Id: Ic611df123653af3a0f2271394387492e440b5ea8 Reviewed-on: https://chromium-review.googlesource.com/c/1306433Reviewed-by:
-
Jungshik Shin authored
In Chromium tree, ICU is rolled to 63.1. And, auto-roller will soon try to roll ICU in v8 to 63.1. Due to a nodejs trybot issue, autoroll needs a manual intervention. In the meantime, this CL will get rid of other blocking issues for ICU update. Prepare for the ICU roll by revising test/intl as following: * Line breaking loose mode is now supported in the Chromium's copy of ICU. Adjust the test expectation. * ICU's uloc_* can handle overlong locale ids. Drop tests that are not valid any more. Once ICU is rolled, a couple of TSAN-suppressed tests can be unsuppressed, but that has to be done in a separate CL. Bug: chromium:893196,v8:8272, v8:8110 Test: intl/*, test262/test402/* Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I17f11457b61376b1e8d41bbbc951fa6cd3355a54 Reviewed-on: https://chromium-review.googlesource.com/c/1289369 Commit-Queue: Jungshik Shin <jshin@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#57105}
-
Frank Tang authored
Fix the to be-landed-soon test262 test failure in test262/intl402/Collator/prototype/resolvedOptions/order The spec changed from "any order" to "table " order in https://github.com/tc39/ecma402/pull/279 Bug: v8:8378 Change-Id: I76cfb27ab4219911e6ab2de97f0f34318d5430a3 Reviewed-on: https://chromium-review.googlesource.com/c/1302801 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
- 29 Oct, 2018 14 commits
-
-
Marja Hölttä authored
If PreParser::ParseFormalParameterList detects a stack overflow, make PreParseFunction actually return kPreParseStackOverflow. BUG=chromium:899495 Change-Id: I1f347b56c594c6edd25401b8448ff38117e190a9 Reviewed-on: https://chromium-review.googlesource.com/c/1304536 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57103}
-
Hannes Payer authored
Change-Id: I65b5f879bfc1efb2ed3178cdfcb3b6a03b91e12a Reviewed-on: https://chromium-review.googlesource.com/c/1305933Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57102}
-
Tobias Tebbi authored
Bug: chromium:899535 Change-Id: I468912afca9187b47ae94fbbcff79e175fa1e686 Reviewed-on: https://chromium-review.googlesource.com/c/1304296Reviewed-by:
Caitlin Potter <caitp@igalia.com> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57101}
-
Frank Tang authored
Change the order of the output and add spec text. To fix the to-be-landed-soon test262 test failure in test262/intl402/Segmenter/prototype/resolvedOptions/order The spec change from "any order" to "table " order in https://github.com/tc39/ecma402/pull/279 Bug: v8:8376 Change-Id: Ife19aec4386a022168514053830ebe03f983f4a9 Reviewed-on: https://chromium-review.googlesource.com/c/1301646Reviewed-by:
-
Frank Tang authored
This will give us some clusterfuzz coverage. Bug: v8:6891 Change-Id: I167774aeb0110bde8d5ed1047b2875b14317903b Reviewed-on: https://chromium-review.googlesource.com/c/1301643Reviewed-by:
-
Hannes Payer authored
Bug: chromium:897074 Change-Id: I8f886647eaab80a6d283b3f1aef6575f36327ec7 Reviewed-on: https://chromium-review.googlesource.com/c/1304543Reviewed-by:
-
Junliang Yan authored
R=joransiu@ca.ibm.com Change-Id: I071409177a0a33ad90c38c787d867461be5085a9 Reviewed-on: https://chromium-review.googlesource.com/c/1302802Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#57097}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: If7d1237bd65b58eaf7fe305f8539a6663b748b05 Reviewed-on: https://chromium-review.googlesource.com/c/1304541Reviewed-by:
-
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:
-
Maya Lekova authored
This reverts commit bf3d7b9a. Reason for revert: Breaks TSAN build, see https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20TSAN/23248 Original change's description: > [wasm] Store compile errors in CompilationState > > We are currently storing compilation errors in the individual > compilation units and pass it to the ErrorThrower during finishing. > This CL changes that to store errors on the CompilationState directly. > From there, it is propagated to the ErrorThrower in the compilation > state callback. > This removes more work from the finisher task and slims down the > WasmCompilationUnits. > > R=mstarzinger@chromium.org > > Bug: v8:8343, v8:7921 > Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9 > Reviewed-on: https://chromium-review.googlesource.com/c/1303720 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57091} TBR=mstarzinger@chromium.org,clemensh@chromium.org Change-Id: Id32c7337494a4749485adbcfcaae7b2331afea66 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8343, v8:7921 Reviewed-on: https://chromium-review.googlesource.com/c/1304544Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#57094}
-
Stephan Herhut authored
As the wasm compilation pipeline skips the start and end phase of normal pipelines, we do not log compilation start/end for functions, which makes reading log output more complicated than need be. Change-Id: I1566ab7428b2dd9763c443000e946d4c6c789626 Reviewed-on: https://chromium-review.googlesource.com/c/1304540Reviewed-by:
-
Clemens Hammacher authored
This removes more parameters which can be queried from the NativeModule. R=titzer@chromium.org Bug: v8:8343 Change-Id: Ia5111a336e8e2272f189ff2c5523afec8b2de660 Reviewed-on: https://chromium-review.googlesource.com/c/1303723Reviewed-by:
-
Clemens Hammacher authored
We are currently storing compilation errors in the individual compilation units and pass it to the ErrorThrower during finishing. This CL changes that to store errors on the CompilationState directly. From there, it is propagated to the ErrorThrower in the compilation state callback. This removes more work from the finisher task and slims down the WasmCompilationUnits. R=mstarzinger@chromium.org Bug: v8:8343, v8:7921 Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9 Reviewed-on: https://chromium-review.googlesource.com/c/1303720Reviewed-by:
-
Benedikt Meurer authored
For NumberMin and NumberMax we don't need to go to Float64 when the inputs are known to be in SafeInteger range, instead we can go to Word64 on 64-bit architectures. This is preliminary work for the huge DataView support, since we'll utilize NumberMax in that case to clamp the limit for the bounds check. Bug: v8:8178, v8:8383 Change-Id: I414114229c5c86b92749d30d645cedc641541ae4 Reviewed-on: https://chromium-review.googlesource.com/c/1304535Reviewed-by:
-
