- 12 Sep, 2017 18 commits
-
-
Jakob Kummerow authored
Saving some binary size. Change-Id: I73765b855310e8152f3c66d2f668efeb2e5c36ce Reviewed-on: https://chromium-review.googlesource.com/661578Reviewed-by:
Franziska Hinkelmann <franzih@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47979}
-
Maya Lekova authored
Bug: chromium:763683, v8:6560 Change-Id: I0769a8a2280a08fe0c768b6330d15cfbb1500f6b Reviewed-on: https://chromium-review.googlesource.com/663218Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#47978}
-
Josh Wolfe authored
R=littledan@chromium.org, adamk@chromium.org CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng Bug: v8:5244 Change-Id: Ib1ca48a843f017c6dcea430af08afbc170c9650d Reviewed-on: https://chromium-review.googlesource.com/661889Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Josh Wolfe <jwolfe@igalia.com> Cr-Commit-Position: refs/heads/master@{#47977}
-
Adam Klein authored
As part of that change, make ToNumber return in the accumulator. Bug: v8:6791 Change-Id: I8ce0f4fbc7ad8ee7fb4a32a8a499394395010750 Reviewed-on: https://chromium-review.googlesource.com/658082Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47976}
-
Martyn Capewell authored
Merge some stack operations to work on an even number of registers, adding a padding register where necessary. Some lightly-used macro assembler functions are inlined, to make pairing registers easier. Not all merges create an even number of register arguments yet. This is a step towards aligning the stack pointer to 16-bytes. Bug: v8:6644 Change-Id: I995510cf91fa1f7af659a8d9b83acf7857787100 Reviewed-on: https://chromium-review.googlesource.com/654607 Commit-Queue: Martyn Capewell <martyn.capewell@arm.com> Reviewed-by:
-
Benedikt Meurer authored
During JSTypedLowering, when we see a JSAdd where we know that at least one side is already a String, we can try to strength-reduce the other side to a string as well. And once we have that, check whether both sides are now String constants, and if the concatenation won't overflow the string length limit, we can just constant-fold the StringAdd. This improves the Six Speed template_string benchmarks by up to 5x, as we no longer need to perform the String concatenations on every loop iteration. Bug: v8:6815 Change-Id: I8c47b2adf66b585d2f191cf805604b435f6256cd Also-By: jarin@chromium.org Reviewed-on: https://chromium-review.googlesource.com/663181 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#47974}
-
Andreas Rossberg authored
As per spec. R=ahaas@chromium.org Change-Id: I46d4bdd444452fef05c234688c27aad8d086bf61 Reviewed-on: https://chromium-review.googlesource.com/663457Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Rossberg <rossberg@chromium.org> Cr-Commit-Position: refs/heads/master@{#47973}
-
Benedikt Meurer authored
So far we didn't properly constant-fold JSToString operators in JSTypedLowering where the input was a known number constant. Bug: v8:6815 Change-Id: Iac87346b7d38f0f75461f285ea7daa2d5a5e1524 Reviewed-on: https://chromium-review.googlesource.com/663358Reviewed-by:
-
Mostyn Bramley-Moore authored
Linux builds have an include chain from src/perf-jit.cc: sys/mman.h -> bits/mman.h -> bits/mman-linux.h, which defines a MAP_TYPE macro that conflicts with InstanceType::MAP_TYPE in jumbo builds, for some jumbo_file_merge_limit values. Since MAP_TYPE isn't used in perf-jit.cc, it should be safe to #undef the macro immediately after the sys/mman.h #include statement. Bug: chromium:746958 Change-Id: I1339a4f56cf6783bf6121cd44c93e776af9458ba Reviewed-on: https://chromium-review.googlesource.com/654042Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com> Cr-Commit-Position: refs/heads/master@{#47971}
-
Clemens Hammacher authored
This further reduces the amount of test-specific code. It will also help testing the wasm baseline compiler, since it is also being called from the {WasmCompilationUnit}. Also, move the {RuntimeExceptionSupport} flag from the {WasmFunctionCompiler} to the {TestingModuleBuilder}. There is no need to store this per function builder. The {TestingModuleBuilder} then passes it on to the {WasmCompilationUnit}, which finally sets it on the {WasmGraphBuilder}. R=mtrofin@chromium.org Bug: v8:6600 Change-Id: I783dc296297a5ca37a2dd0d2035d782ca19a0fee Reviewed-on: https://chromium-review.googlesource.com/660239 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47970}
-
Clemens Hammacher authored
We were using a boolean before, which makes the meaning non-obvious when passed as a parameter. With the enum, you actually have to use {kRuntimeExceptionSupport} or {kNoRuntimeExceptionSupport}. R=mtrofin@chromium.org Change-Id: Iaf5a7b6f1b446d4c3e16e044a6055d923d3b0b49 Reviewed-on: https://chromium-review.googlesource.com/660738 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
pan.deng@intel.com authored
Contributed by kanghua.yu@intel.com. Bug: None Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9 Reviewed-on: https://chromium-review.googlesource.com/604648Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Ivica Bogosavljevic authored
Bug: Change-Id: Ifb4d3c8d085ebaf0eaed2c4648871488d94a6997 Reviewed-on: https://chromium-review.googlesource.com/662782Reviewed-by:
Miran Karić <Miran.Karic@imgtec.com> Reviewed-by:
Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Cr-Commit-Position: refs/heads/master@{#47967}
-
Camillo Bruni authored
Bug: v8:6211 Change-Id: If61c91e65abf0201651b894e348a7b342c5d0968 Reviewed-on: https://chromium-review.googlesource.com/654662Reviewed-by:
-
Clemens Hammacher authored
R=ahaas@chromium.org Change-Id: I9b8a00061fe202b8c18426626b496c15455c8b7f Reviewed-on: https://chromium-review.googlesource.com/660280Reviewed-by:
-
Clemens Hammacher authored
Instead of four different constructors, we actually just need one. You either pass a Counters*, or we will get it from the isolate (which is only allowed to happen on the main thread). This change makes refactoring this data structure for the baseline compiler much easier. R=mtrofin@chromium.org CC=kschimpf@chromium.org Bug: v8:6600 Change-Id: I56fb47005861dd4a203373776901930a02e09deb Reviewed-on: https://chromium-review.googlesource.com/657979Reviewed-by:
-
Benedikt Meurer authored
When accessing elements of a global (constant) JSArray, whose backing store is copy-on-write, we can just constant-fold the value and insert a check that the backing store stays the same. Bug: v8:6816, v8:6815 Change-Id: I090bcec7b1ce72a1f9ed8625680ed91e8c67f27f Reviewed-on: https://chromium-review.googlesource.com/662757Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47963}
-
Jakob Gruber authored
This reverts commit ddb5255f. Reason for revert: Mission accomplished / Canary 3213 / V8 6.3.104 Original change's description: > Reland "[snapshot] Temporarily enable --lazy-deserialization" > > This is a reland of da6aab43 > Original change's description: > > [snapshot] Temporarily enable --lazy-deserialization > > > > Flip the flag for one day to determine impact and flush out bugs. > > Please add crashes and regressions to https://crbug.com/v8/6796. > > > > Bug: v8:6624,v8:6796 > > Change-Id: I8b0581c40d956e01f94e9098ff935fdd5af36156 > > Reviewed-on: https://chromium-review.googlesource.com/651408 > > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Michael Hablich <hablich@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#47893} > > Bug: v8:6624, v8:6796 > Change-Id: I7df43925ccb2e6c1d3455439690526b0e1a6a747 > Reviewed-on: https://chromium-review.googlesource.com/660218 > Reviewed-by: Michael Hablich <hablich@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47952} TBR=yangguo@chromium.org,hablich@chromium.org,jgruber@chromium.org Change-Id: Ia0f6dc05132b66a093d4df5ec470709b53aa17d6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6624, v8:6796 Reviewed-on: https://chromium-review.googlesource.com/662797Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47962}
-
- 11 Sep, 2017 22 commits
-
-
Josh Wolfe authored
R=littledan@chromium.org, adamk@chromium.org CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng Bug: v8:5601 Change-Id: Ie3edaa82957028100249b2d543e761233cd0d074 Reviewed-on: https://chromium-review.googlesource.com/661065Reviewed-by:
-
Deepti Gandluri authored
- Memory.Grow with guard pages enabled should adjust amount of allocated memory, and not allocate a new buffer. This was disabled because previously the backing store was freed in the MemoryFinalizer, and we needed to be sure that the backing store is not released till the last buffer using it is released. This is now safe as we no longer use the MemoryFinalizer - SetProtection should use Guard/Unprotect that use mprotect underneath, instead of CommitRegion/UncommitRegion that use mmap - Move buffer allocation to the end to avoid inconsistent memory due to GC BUG=v8:5886 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I0d7edb884bd1e3167eb5fbced6953c6401688d40 Reviewed-on: https://chromium-review.googlesource.com/629517Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Reviewed-by:
Eric Holk <eholk@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#47960}
-
Jaideep Bajwa authored
R=joransiu@ca.ibm.com, jyan@ca.ibm.com BUG= LOG=N Change-Id: Ic3d594bd69d6979aeab46a655cfa4ef530d80d57 Reviewed-on: https://chromium-review.googlesource.com/661477Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47959}
-
Alexey Kozyatinskiy authored
+ little reduction of injected-script-source size. Bug: chromium:759651 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia5d0b31fddc9f6c6c7e547618a6a01e93564bcbc Reviewed-on: https://chromium-review.googlesource.com/660409Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47958}
-
Ben Smith authored
It causes a significant regression in TypedArray benchmarks. Thinking it through, it is actually not necessary for the JavaScript memory model either. I originally added it to ensure that reads/writes are not elided or duplicated, but there is no guarantee of this behavior for non-atomic writes in the model. BUG=chromium:763814 R=clemensh@chromium.org Change-Id: Ib03d2e2e77a846d4b9e84eebc7f8fbf861f8fd7c Reviewed-on: https://chromium-review.googlesource.com/661192Reviewed-by:
-
Georg Neis authored
BigInt is a new primitive type of arbitrary precision integers, proposed in https://tc39.github.io/proposal-bigint. This CL introduces a corresponding instance type, map, and C++ class to V8 and adds BigInt support to a few operations (see the test file). Much more is to come. Also, the concrete representation of BigInts is not yet fixed, currently a BigInt is simply a wrapped Smi. Bug: v8:6791 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45 Reviewed-on: https://chromium-review.googlesource.com/657022Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Deepti Gandluri authored
Change-Id: I960bd425e5ebd4cda1c44c6a6f085b1553d01a29 Reviewed-on: https://chromium-review.googlesource.com/660404Reviewed-by:
-
Daniel Ehrenberg authored
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I3f07c8c5359297c061d1cf10d1c3f7bb2919c78e Reviewed-on: https://chromium-review.googlesource.com/660278Reviewed-by:
-
Jungshik Shin authored
This will introduce a new behavior on POSIX(-like) platforms. Timezone names inside parentheses after GMT offset will not be 3-4 letter abbreviation any longer. They'll be human-readable names in the current default locale. This matches the current Windows behavior. new Date(2017, 5, 22).toString() new Date(2017, 11, 22).toString() Current: Thu Jun 22 2017 00:00:00 GMT-0700 (PDT) Fri Dec 22 2017 00:00:00 GMT-0800 (PST) New in en-US locale: Thu Jun 22 2017 00:00:00 GMT-0700 (Pacific Daylight Time) Fri Dec 22 2017 00:00:00 GMT-0800 (Pacific Standard Time) New in German locale: Thu Jun 22 2017 00:00:00 GMT-0700 (Nordamerikanische Westküsten-Sommerzeit) Fri Dec 22 2017 00:00:00 GMT-0800 (Nordamerikanische Westküsten-Normalzeit) BUG=v8:6031, v8:2137, v8:6076 TEST=mjsunit/icu-date-lord-howe.js, mjsunit/icu-date-to-string.js Change-Id: I4e7fd8b3ddae5c7779e220c4c101e45904fcdc01 Reviewed-on: https://chromium-review.googlesource.com/625164 Commit-Queue: Jungshik Shin <jshin@chromium.org> Reviewed-by:
Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47953}
-
Jakob Gruber authored
This is a reland of da6aab43 Original change's description: > [snapshot] Temporarily enable --lazy-deserialization > > Flip the flag for one day to determine impact and flush out bugs. > Please add crashes and regressions to https://crbug.com/v8/6796. > > Bug: v8:6624,v8:6796 > Change-Id: I8b0581c40d956e01f94e9098ff935fdd5af36156 > Reviewed-on: https://chromium-review.googlesource.com/651408 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Hablich <hablich@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47893} Bug: v8:6624, v8:6796 Change-Id: I7df43925ccb2e6c1d3455439690526b0e1a6a747 Reviewed-on: https://chromium-review.googlesource.com/660218Reviewed-by:
Michael Hablich <hablich@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47952}
-
Mike Stanton authored
Since we don't have a full-codegen compiler anymore, we no longer generate Code::FUNCTION kind. Nice! Here is some cleanup. Bug: v8:6409 Change-Id: I05634e4ca85c4037b49a4346f4e8bae8042b8762 Reviewed-on: https://chromium-review.googlesource.com/657817 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
Andreas Haas authored
The wasm code for asm.js modules is generated by us and does not come from the user. Therefore we do not need to check in release builds that experimental opcodes are not used for asm.js, a DCHECK is sufficient. R=clemensh@chromium.org Change-Id: I0c7135bfb03eafd2a39e648d57eff8e3a4440c3f Reviewed-on: https://chromium-review.googlesource.com/659938Reviewed-by:
-
Peter Marshall authored
We call this ~140 times from addReferences() and AddStubCache, which caused size to increase. Bug: Change-Id: Ib08d435abb82b3e07121adf023f96f6f0b33733e Reviewed-on: https://chromium-review.googlesource.com/660120Reviewed-by:
-
Toon Verwaest authored
Bug: v8:5269 Change-Id: Ie649a83435f74b6dd705991c264085f28b12736c Reviewed-on: https://chromium-review.googlesource.com/655438 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47948}
-
jgruber authored
This fixes two issues related to Code object allocation: Code objects need to be aligned to kCodeAlignment (= 32), and the instruction cache needs to be flushed after deserialization. Both bugs combined manifested as a crash at a basically arbitrary point in the code after the Runtime::kDeserializeLazy call: 0x286bc8dc: blx r12 // Call to Runtime::kDeserializeLazy, // generated through // GenerateTailCallToReturnedCode. 0x286bc8e0: mov r2, r0 // This seemingly innocent register move // crashes hard. Bug: v8:6624,v8:6796 Change-Id: I88c7eaf57ac851745fb7e800c92b0f5978b33466 Reviewed-on: https://chromium-review.googlesource.com/660119Reviewed-by: -
Andreas Haas authored
The wasm valiation incorrectly allowed simd locals, even without the experimental flag turned on. This was not noted in the generated code because simd opcodes were forbidden, but the interpreter could not handle these locals. R=clemensh@chromium.org Bug: chromium:763697 Change-Id: I11d924ac21e50bce81d0504c2c7b252105a89f80 Reviewed-on: https://chromium-review.googlesource.com/660117 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: If0554f01068fb76228e85cfe120630eda86de41d Reviewed-on: https://chromium-review.googlesource.com/659997Reviewed-by:
-
Clemens Hammacher authored
With jumbo builds, we get spurious errors if several .cc files define the same preprocessor macro without undefining it. This is also disallowed by the style guide. This patch adds a presubmit check to check that each #define is eventually followed by a corresponding #undef. Special care has to be taken for conditionally defined macros. Here, the logic to check that there are not multiple defines and that they are undefined in all cases is not perfect; it's optimistic in order to avoid false positives. R=mstarzinger@chromium.org, machenbach@chromium.org Bug: v8:6811 Change-Id: I55cde499399d97a5eb02fbc5ecfa34e6a8099d06 Reviewed-on: https://chromium-review.googlesource.com/657104 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
Cleanup before enabling the presubmit check: https://chromium-review.googlesource.com/c/v8/v8/+/657104 Bug: v8:6811 R=ahaas@chromium.org CC=mstarzinger@chromium.org Change-Id: Ifbf9210464b46dfdb5e04fbedc41d30e11536f74 Reviewed-on: https://chromium-review.googlesource.com/657422Reviewed-by:
-
Benedikt Meurer authored
The Typer put the wrong type on String#index and String#lastIndexOf builtins, with an off by one on the upper bound. Bug: chromium:762874 Change-Id: Ia4c29bc2e8e1c85b6a7ae0b99f8aaabf839a5932 Reviewed-on: https://chromium-review.googlesource.com/660000Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47942}
-
Andreas Haas authored
In the test case the module contained a memory which got exported by the name 'main'. The fuzzer crashed when it tried to cast the memory to a function to execute it. This CL checks that 'main' is a function before doint the cast. R=clemensh@chromium.org Bug: chromium:763349 Change-Id: I9a21413c8038a7547f8b59057afea2870b15499a Reviewed-on: https://chromium-review.googlesource.com/659978Reviewed-by:
-
Benedikt Meurer authored
TurboFan wasn't able to inline calls to Array.prototype.push which didn't have exactly one parameter. This was a rather artifical limitation and was mostly due to the way the MaybeGrowFastElements operator was implemented (which was not ideal by itself). Refactoring this a bit, allows us to inline the operation in general, independent of the number of values to push. Array#push with multiple parameters is used quite a lot inside Ember (as discovered by Apple, i.e. https://bugs.webkit.org/show_bug.cgi?id=175823) and is also dominating the Six-Speed/SpreadLiterals/ES5 benchmark (see https://twitter.com/SpiderMonkeyJS/status/906528938452832257 from the SpiderMonkey folks). The micro-benchmark mentioned in the tracking bug (v8:6808) improves from arrayPush0: 2422 ms. arrayPush1: 2567 ms. arrayPush2: 4092 ms. arrayPush3: 4308 ms. to arrayPush0: 798 ms. arrayPush1: 2563 ms. arrayPush2: 2623 ms. arrayPush3: 2773 ms. with this change, effectively removing the odd 50-60% performance cliff that was associated with going from one parameter to two or more. Bug: v8:2229, v8:6808 Change-Id: Iffe4c1233903c04c3dc2062aad39d99769c8ab57 Reviewed-on: https://chromium-review.googlesource.com/657582Reviewed-by:
-
