- 01 Mar, 2018 14 commits
-
-
Sigurd Schneider authored
This CL adds a regression benchmark for a fast-path of String.p.charCodeAt, which is important for node.js. Bug: v8:7326 Change-Id: I54efaa2988c595dd40e6a55a3464b3ee7de6f07b Reviewed-on: https://chromium-review.googlesource.com/942885Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#51654}
-
Michael Hablich authored
TBR=machenbach@chromium.org Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I4b5675a02364631f88f203b5c60edc14314a4617 Reviewed-on: https://chromium-review.googlesource.com/942904 Commit-Queue: Michael Hablich <hablich@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#51653}
-
Clemens Hammacher authored
R=ahaas@chromium.org Bug: v8:7508, v8:6600 Change-Id: I9eb04171eb489383bb746e2d04c6ffff304b7918 Reviewed-on: https://chromium-review.googlesource.com/942821Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51652}
-
Clemens Hammacher authored
MSVC 2015 and 2017 implement std::is_trivially_copyable, but not correctly. Hence, reimplement it using more low-level primitives. For stdlibc++ versions below 5.0, we already have a workaround for the missing support of std::is_trivially_copyable, but this is an unsound approximation, because it is ignoring move constructor, move assignment and copy assignment. Therefore, do not use this approximation for asserting trivial copyability of a type. Finally, add unittests for the new is_trivially_copyable implementations. R=mstarzinger@chromium.org CC=loorongjie@gmail.com Change-Id: I9ee56a65882e8c94b72c9a2d484edd27963a5d89 Reviewed-on: https://chromium-review.googlesource.com/941521Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51651}
-
Gabriel Charette authored
and use it for parallel GC as it blocks the main thread. On Chromium this will result in a TaskPriority::USER_BLOCKING task, allowing TaskScheduler to prioritize them above all other async work. R=ahaas@chromium.org Bug: chromium:817421 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I8c782eb045035ce2899214528deae5a45f0e6600 Reviewed-on: https://chromium-review.googlesource.com/941946 Commit-Queue: Gabriel Charette <gab@chromium.org> Reviewed-by:
-
Ivica Bogosavljevic authored
Some macros in test-assembler-mips have the same name as newly introduced macros in sid sysroot. We rename them in order to prevent compilation problems Change-Id: I84d9562f39c1aca8ac20e979466862228f438425 Reviewed-on: https://chromium-review.googlesource.com/942322Reviewed-by:
-
Georg Neis authored
Bug: v8:7446 Change-Id: Ic4eaeeb1e4852cffde679b359e562a48e5ba39e9 Reviewed-on: https://chromium-review.googlesource.com/942922 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Ilija Pavlovic authored
Introducing a new status-file variable: mips_arch_variant. With this variable, in status files will be possible to define selections which are based on MIPS architecture revisions/variants. TEST= BUG= Change-Id: Ifd682552db2f26be4e56dc94ad50bed063ff14c5 Reviewed-on: https://chromium-review.googlesource.com/941212Reviewed-by:
-
jgruber authored
External references are process-specific and thus need to be accessed through an indirection (or reloc'd by the linker). This CL moves all used external references to the builtins constants table and rewrites accesses to load from there. In the future, this could be made more efficient by removing levels of indirection or using the native linker. Bug: v8:6666 Change-Id: I63491670549654edeb59c60bb833acfdc5a48495 Reviewed-on: https://chromium-review.googlesource.com/939783Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51646}
-
Gabriel Charette authored
With a temporary intermediate step to allow adapting embedders before getting rid of the ExpectedRuntime method altogether. The method is being renamed to CallOnWorkerThread() as an effort to go away from "background" nomenclature for worker threads ("background" usually refers to a priority but worker threads are commonly used for high priority tasks in v8). Other CLs will follow to rename other "background" APIs. Bug: v8:7310 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2fd4eac7458708d4eacb0f4871c982a567a3865e Reviewed-on: https://chromium-review.googlesource.com/941442 Commit-Queue: Gabriel Charette <gab@chromium.org> Reviewed-by: -
Kim-Anh Tran authored
Bug: v8:7310 Change-Id: I87bdb640a3c006a268974b34808f184307badeb2 Reviewed-on: https://chromium-review.googlesource.com/934243 Commit-Queue: Kim-Anh Tran <kimanh@google.com> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51644}
-
Camillo Bruni authored
Bug: v8:7310 Change-Id: I328fd1b9ebff405f827f7ef810ab1e8459582fca Reviewed-on: https://chromium-review.googlesource.com/941203Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51643}
-
jing.bao authored
Also Add vhaddps to x64 Fix haddps for SSE3 scope and disassembler on ia32/x64 Change-Id: If511e6428fa1ce034b4281943dfee1405c9d4ffc Reviewed-on: https://chromium-review.googlesource.com/939265Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Jing Bao <jing.bao@intel.com> Cr-Commit-Position: refs/heads/master@{#51642}
-
Kanghua Yu authored
kind = BYTECODE_HANDLER name = Wide compiler = turbofan Body (size = 64) Instructions (size = 56) -- Prologue: generate speculation poison -- 0x3f54d38b5c0 0 488d1df9ffffff REX.W leaq rbx,[rip+0xfffffff9] 0x3f54d38b5c7 7 49c7c100000000 REX.W movq r9,0x0 => ... Body (size = 60) Instructions (size = 52) -- Prologue: generate speculation poison -- 0x3f54d38b5c0 0 488d1df9ffffff REX.W leaq rbx,[rip+0xfffffff9] 0x3f54d38b5c7 7 4533c9 xorl r9,r9 Change-Id: I2e3926a01423a979fd77cfc0c0081f049bb01eb8 Reviewed-on: https://chromium-review.googlesource.com/940778Reviewed-by:
-
- 28 Feb, 2018 22 commits
-
-
Erik Luo authored
Bug: chromium:810176 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I16e4148434f5cbf44058e1aa5f01693bcba82d0a Reviewed-on: https://chromium-review.googlesource.com/932943 Commit-Queue: Erik Luo <luoe@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#51640}
-
Georg Neis authored
R=jkummerow@chromium.org Bug: v8:7505, v8:6791 Change-Id: I11b0031dfafa499a813e3e52080ee5542224799a Reviewed-on: https://chromium-review.googlesource.com/941130Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#51639}
-
Georg Neis authored
For namespace objects, [[GetOwnProperty]] on an uninitialized property throws a ReferenceError. This was not implemented everywhere. This CL fixes all such issues I'm aware of. Bug: v8:7470 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I5f024450005c4f4dcb3f41c844ef055f67a9a869 Reviewed-on: https://chromium-review.googlesource.com/937341Reviewed-by:
-
Jakob Kummerow authored
The assert-guarded comment claiming that ToNumber could not possibly neuter the target array unfortunately turns out to have been wishful thinking. Bug: chromium:816961 Change-Id: Ib98f96f4cd7f33414c0b5a6037bfb881938cc15e Reviewed-on: https://chromium-review.googlesource.com/939767 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Nico Weber authored
gcc and clang (and the standard) don't allow implicit conversion of function pointers to object pointers. MSVC does allow that, and since system headers require this to work, clang-cl allows it too -- but it emits a -Wmicrosoft-cast warning (which we currently suppress in the Chromium build, but which we want to enable.) As a side effect, when printing a function pointer to a stream, MSVC (and clang-cl) will pick the operator<<(void*) overload, while gcc and clang will pick operator<<(bool) since the best allowed conversion they find is from function pointer to bool. To prevent the clang-cl warning, we need to make sure that we never directly print a function pointer to a stream. In v8, this requires two changes: 1. Give PrintCheckOperand() an explicit specialization for function pointers and explicitly cast to void* there. This ports https://codereview.chromium.org/2515283002/ to V8, and also fixes a bug on non-Windows where DCHECK() of function pointers would print "(1 vs 1)" instead of the function's addresses. (The bug remains with member function pointers, where it's not clear what to print instead of the 1.) 2. has_output_operator<T> must not use operator<< on its argument in an evaluated context if T is a function pointer. This patch modifies has_output_operator<> to use an unevaluated context instead, which is simpler than the current approach (and matches what Chromium's base does), but changes behavior in minor (boring) ways (see template-utils-unittest.cc), since operator<<() is now called with a temporary and only operator<<() implementations callable with a temporary are considered. A more complicated but behavior-preserving alternative would be to add an explicit specialization for function pointers. You can see this variant in patch set 1 on gerrit. Bug: chromium:550065 Change-Id: Idc2854d6c258b7fc0b959604006d8952a79eca3d Reviewed-on: https://chromium-review.googlesource.com/940004 Commit-Queue: Nico Weber <thakis@chromium.org> Reviewed-by:
-
Andreas Haas authored
Due to a recent refactoring the function EnsureEventLoopInitialized on the default platform became obsolete. It does not contain a single line of code. With this CL we prepare the removal of this function from the V8 platform API. R=rmcilroy@chromium.org Bug: v8:7310 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: If4d54cd989f8df2f40b322be3b67bb8a482398d0 Reviewed-on: https://chromium-review.googlesource.com/934221 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Mathias Bynens authored
This brings us closer to our goal of deprecating the `construct_stub` field in `SharedFunctionInfo`. Bug: v8:7503 Change-Id: I9502246f5e463e487a989ab7f8c96c008f0fa9d9 Reviewed-on: https://chromium-review.googlesource.com/941143 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
-
Mathias Bynens authored
This brings us closer to our goal of deprecating the `construct_stub` field in `SharedFunctionInfo`. Bug: v8:7503 Change-Id: Id7bee0d61830f7bcf2cad4f6e50ff9f24b58a51b Reviewed-on: https://chromium-review.googlesource.com/939790Reviewed-by:
-
Andreas Haas authored
R=clemensh@chromium.org Change-Id: Ib6f0c0de813049192ea99b194d5ef4b17d44cd72 Reviewed-on: https://chromium-review.googlesource.com/939784Reviewed-by:
-
Sigurd Schneider authored
This CL also reorganizes the Strings test suite Bug: v8:7340 Change-Id: I54d4d76a16c362e38ebfc9719ac8cb1a490ef3cc Reviewed-on: https://chromium-review.googlesource.com/941122Reviewed-by:
-
Benedikt Meurer authored
Next step on deprecating the construct_stub field in the SharedFunctionInfo. Bug: v8:7503 Change-Id: Ibcbf9dc0dbcbcf0e26c103167e8a30074cbdd888 Reviewed-on: https://chromium-review.googlesource.com/940942Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51630}
-
Mathias Bynens authored
This brings us closer to our goal of deprecating the `construct_stub` field in `SharedFunctionInfo`. Bug: v8:7503 Change-Id: I0e995e6ed9e7c04990f76dd8fe8afaaa8d38294b Reviewed-on: https://chromium-review.googlesource.com/940124 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
Bug: v8:7250, v8:7340 Change-Id: I6267787d297b0aab698b8b38d475f6eff61a730f Reviewed-on: https://chromium-review.googlesource.com/921523Reviewed-by:
-
Mathias Bynens authored
This brings us closer to our goal of deprecating the `construct_stub` field in `SharedFunctionInfo`. Bug: v8:7503 Change-Id: I215539fb8ac52fd437d3c04a02ecba2cd38cd101 Reviewed-on: https://chromium-review.googlesource.com/940125Reviewed-by:
-
Mathias Bynens authored
This brings us closer to our goal of deprecating the `construct_stub` field in `SharedFunctionInfo`. Bug: v8:7503 Change-Id: I20e6c7d58e7cdcc7316e35568357a4ad3059a892 Reviewed-on: https://chromium-review.googlesource.com/940129Reviewed-by:
-
Benedikt Meurer authored
This is the first step on the way to eventually get rid of the construct_stub field in SharedFunctionInfos. Bug: v8:7503 Change-Id: Ib14627613851c7f2a5ab795c642bb74176285863 Reviewed-on: https://chromium-review.googlesource.com/940222Reviewed-by:
-
Sigurd Schneider authored
Bug: v8:7250, v8:7340 Change-Id: Ice54ee684f77a575d7479f4e7d4fdb55e7427da9 Reviewed-on: https://chromium-review.googlesource.com/919164 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
If memory is statically known to be out of bounds, do not generate code for the load or store, and also mark the rest of the current block unreachable to avoid unnecessary code generation. This also prevents us from having to special-case illegal memory offsets in the LiftoffAssembler. For valid code, the offset will always be smaller than 2GB. R=ahaas@chromium.org Bug: v8:6600 Change-Id: Ib5a9006780098e9f2ab9eda4bac7939f15612ae0 Reviewed-on: https://chromium-review.googlesource.com/939821Reviewed-by:
-
Clemens Hammacher authored
According to the spec, exported wasm functions should not have a [[Construct]] method, hence they don't have a prototype. R=bmeurer@chromium.org CC=titzer@chromium.org Bug: v8:7503 Change-Id: I9e142d65a80c0ef6dbd743421771f194c2d50614 Reviewed-on: https://chromium-review.googlesource.com/939782Reviewed-by:
-
Junliang Yan authored
Port be4cd67c Original Commit Message: This adds support for poisoning the stack pointer and implicit register arguments like the context register and the function register in the prologue of generated code with JavaScript linkage. The speculation poison is computed similarly to the interpreter by matching expected with actual code start addresses. R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:798964 LOG=N Change-Id: I0d015fd8a8f05982d947a4a1c0be1a825ac19d64 Reviewed-on: https://chromium-review.googlesource.com/940460Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#51621}
-
Junliang Yan authored
Port 5586ecfc Original Commit Message: This decouples the checking of the {kJavaScriptCallCodeStartRegister} from the deoptimization checks. We now rely more heavily on the above register and should check its validity more broadly. Note that there also is a bug fix for the ARM port contained in this change. R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ic8b58994b083c6c0ec73173120cedf6391b1c964 Reviewed-on: https://chromium-review.googlesource.com/938522Reviewed-by:
-
Junliang Yan authored
This is a reland of 89737c5d. Original change's description: > PPC/s390: [turbofan] Ensure instruction start is in fixed register. > > Port c462ddc8 > > Original Commit Message: > > This makes sure that {JSFunction} invocations always load the code start > address into the fixed {kJavaScriptCallCodeStartRegister} register. This > allows us to perform PC-relative operations more effective. For now this > only applies to code with {kCallJSFunction} linkage. > > R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com > BUG= > LOG=N > > Change-Id: If346a3cbaea820b1fcec38c5105605496961a888 > Reviewed-on: https://chromium-review.googlesource.com/938721 > Reviewed-by: Joran Siu <joransiu@ca.ibm.com> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Junliang Yan <jyan@ca.ibm.com> > Cr-Commit-Position: refs/heads/master@{#51608} Change-Id: I5b118c3903847cc13e2ce228e9713f8ae55ce193 Reviewed-on: https://chromium-review.googlesource.com/940342Reviewed-by:
-
- 27 Feb, 2018 4 commits
-
-
Michael Achenbach authored
TBR=iannucci@chromium.org NOTRY=true Change-Id: I6bee8db469b43a01402798953a1bcdaf3dc06cf7 Reviewed-on: https://chromium-review.googlesource.com/940421 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Junliang Yan authored
This reverts commit 89737c5d. Reason for revert: Sorry, missed the portion in code-generator Original change's description: > PPC/s390: [turbofan] Ensure instruction start is in fixed register. > > Port c462ddc8 > > Original Commit Message: > > This makes sure that {JSFunction} invocations always load the code start > address into the fixed {kJavaScriptCallCodeStartRegister} register. This > allows us to perform PC-relative operations more effective. For now this > only applies to code with {kCallJSFunction} linkage. > > R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com > BUG= > LOG=N > > Change-Id: If346a3cbaea820b1fcec38c5105605496961a888 > Reviewed-on: https://chromium-review.googlesource.com/938721 > Reviewed-by: Joran Siu <joransiu@ca.ibm.com> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Junliang Yan <jyan@ca.ibm.com> > Cr-Commit-Position: refs/heads/master@{#51608} TBR=mstarzinger@chromium.org,michael_dawson@ca.ibm.com,jyan@ca.ibm.com,joransiu@ca.ibm.com Change-Id: I9a0810aa35ff39651397055ab53d250c2f6f09e0 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/940341Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#51617}
-
Eric Holk authored
This also adds a DCHECK that the buffer does not have guard pages in MaterializeArrayBuffer because the code there does not know how correctly set up a buffer with guard pages. Bug: chromium:801849 Change-Id: Ic761fcdfbd16a2d6e87f4eb135f5d03b7aa2d71d Reviewed-on: https://chromium-review.googlesource.com/938968Reviewed-by:
-
Michael Achenbach authored
NOTRY=true TBR=sergiyb@chromium.org Change-Id: Ic67a1cc7e58143df6fc0d8c2199578007e0e960b Reviewed-on: https://chromium-review.googlesource.com/939874 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
