- 31 Oct, 2019 1 commit
-
-
Michaël Zasso authored
This gets rid of a bunch of compiler warnings with MSVC. Change-Id: I73440f0d203603fe39a2408d2b9cc647700aa5fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893334Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Michaël Zasso <mic.besace@gmail.com> Cr-Commit-Position: refs/heads/master@{#64692}
-
- 23 Oct, 2019 1 commit
-
-
Michael Starzinger authored
The {InstructionCode} is only used to store plain (non-negative) values of the {ArchOpcode} enum, or additionally encodes {BitField} values. The underlying base type 'U' of a {BitField} is uint32_t. To avoid all the numerous implicit conversions between int32_t and uint32_t, this is changing the {InstructionCode} so that uint32_t is used exclusively. R=neis@chromium.org BUG=v8:9872 Change-Id: If64107ad9298011e219b4827735eafb51465beb0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869193Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64503}
-
- 17 Oct, 2019 1 commit
-
-
Milad Farazmand authored
The calling conventions on AIX uses function descriptors, which means that pointers to functions do not point to code, but instead point to metadata about them. When calling JITed code, we must assure to use function descriptors instead of raw pointers when needed. Before this CL 213504b9, all CallCFunction on AIX were guaranteed to have function descriptors. Starting form the CL mentioned above, CallCFunction can also Jump to a Trampoline which does not have a function descriptor, hence a new "CallCFunctionWithoutFunctionDescriptor" method is proposed to deal with this issue. BUG= v8:9766 Change-Id: I9343c31c812f5d4dda8503a5adf024b24dbde072 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1825961 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64357}
-
- 24 Sep, 2019 1 commit
-
-
Ng Zhi An authored
This gives nicer error messages. Was Fatal error in ../../src/compiler/backend/instruction.h, line 778 Debug check failed: i < InputCount(). Now Fatal error in ../../src/compiler/backend/instruction.h, line 778 Debug check failed: i < InputCount() (5 vs. 3). Bug: v8:9396 Change-Id: Iab2aea49245a42397bf07f4abf9e3de501c758b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1817258Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#63954}
-
- 10 Sep, 2019 1 commit
-
-
Michael Starzinger authored
R=mvstanton@chromium.org BUG=v8:9396 Change-Id: Iaf1f6af19d3c4236c6f1c4b215b90b2e390e81d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789297 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#63631}
-
- 26 Aug, 2019 1 commit
-
-
Maya Lekova authored
This is a reland of 8ff8ddba Original change's description: > [turbofan] Further brokerize BytecodeGraphBuilder > > Replace all usages of VectorSlotPair with FeedbackSource. > > Bug: v8:7790 > Change-Id: I0ac6e9cd8f5730154cc1842e267ca1ebfdebc874 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763536 > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63378} Bug: v8:7790 Change-Id: I54fbf4433a65681780fda4ded09ec2d145d36ec1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768361Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63391}
-
- 23 Aug, 2019 2 commits
-
-
Bill Budge authored
This reverts commit 8ff8ddba. Reason for revert: Causes failures on GC Stress and TSan: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24138 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/27969 Original change's description: > [turbofan] Further brokerize BytecodeGraphBuilder > > Replace all usages of VectorSlotPair with FeedbackSource. > > Bug: v8:7790 > Change-Id: I0ac6e9cd8f5730154cc1842e267ca1ebfdebc874 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763536 > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63378} TBR=neis@chromium.org,mslekova@chromium.org Change-Id: Ieb6fb24dd0626fd9eb2183844614ac5b3c8084e8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769287Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#63387}
-
Maya Lekova authored
Replace all usages of VectorSlotPair with FeedbackSource. Bug: v8:7790 Change-Id: I0ac6e9cd8f5730154cc1842e267ca1ebfdebc874 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763536 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63378}
-
- 22 Aug, 2019 3 commits
-
-
Jakob Gruber authored
This is a reland of 1e472c42 No change, this was a speculative revert to unblock the roll. TBR=jgruber Original change's description: > [compiler] Track the maximal unoptimized frame size > > This is another step towards considering the unoptimized frame size in > stack checks within optimized code. > > With the changes in this CL, we now keep track of the maximal > unoptimized frame size of the function that is currently being > compiled. An optimized function may inline multiple unoptimized > functions, so a single optimized frame can deopt to multiple > frames. The real frame size thus differs in different parts of the > optimized function. > > We only care about the maximal frame size, which we calculate > conservatively as an over-approximation, and track in > InstructionSelector::max_unoptimized_frame_height_ for now. In future > work, this value will be passed on to codegen, where it will be > applied as an offset to the stack pointer during the stack check. > > (The motivation behind this is to avoid stack overflows through deopts, > caused by size differences between optimized and unoptimized frames.) > > Note that this offset only ensure that the topmost optimized frame can > deopt without overflowing the stack limit. That's fine, because we only > deopt optimized frames one at a time. Other (non-topmost) frames are > only deoptimized once they are returned to. > > Drive-by: Print variable and total frame height in --trace-deopt. > > Bug: v8:9534 > Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63330} Bug: v8:9534 Change-Id: I686f200e7be1f419e23e50789e11607a0b2886d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1766645 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#63356}
-
Bill Budge authored
This reverts commit 1e472c42. Reason for revert: Speculative revert, to attempt to fix crashes that block the V8 roll. Example failure run: https://ci.chromium.org/p/chromium/builders/try/linux-rel/173465 Original change's description: > [compiler] Track the maximal unoptimized frame size > > This is another step towards considering the unoptimized frame size in > stack checks within optimized code. > > With the changes in this CL, we now keep track of the maximal > unoptimized frame size of the function that is currently being > compiled. An optimized function may inline multiple unoptimized > functions, so a single optimized frame can deopt to multiple > frames. The real frame size thus differs in different parts of the > optimized function. > > We only care about the maximal frame size, which we calculate > conservatively as an over-approximation, and track in > InstructionSelector::max_unoptimized_frame_height_ for now. In future > work, this value will be passed on to codegen, where it will be > applied as an offset to the stack pointer during the stack check. > > (The motivation behind this is to avoid stack overflows through deopts, > caused by size differences between optimized and unoptimized frames.) > > Note that this offset only ensure that the topmost optimized frame can > deopt without overflowing the stack limit. That's fine, because we only > deopt optimized frames one at a time. Other (non-topmost) frames are > only deoptimized once they are returned to. > > Drive-by: Print variable and total frame height in --trace-deopt. > > Bug: v8:9534 > Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63330} TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org Change-Id: I7b225c30bfc4e1d958276583f512a1ec5fa2b458 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9534 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764626Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#63350}
-
Jakob Gruber authored
This is another step towards considering the unoptimized frame size in stack checks within optimized code. With the changes in this CL, we now keep track of the maximal unoptimized frame size of the function that is currently being compiled. An optimized function may inline multiple unoptimized functions, so a single optimized frame can deopt to multiple frames. The real frame size thus differs in different parts of the optimized function. We only care about the maximal frame size, which we calculate conservatively as an over-approximation, and track in InstructionSelector::max_unoptimized_frame_height_ for now. In future work, this value will be passed on to codegen, where it will be applied as an offset to the stack pointer during the stack check. (The motivation behind this is to avoid stack overflows through deopts, caused by size differences between optimized and unoptimized frames.) Note that this offset only ensure that the topmost optimized frame can deopt without overflowing the stack limit. That's fine, because we only deopt optimized frames one at a time. Other (non-topmost) frames are only deoptimized once they are returned to. Drive-by: Print variable and total frame height in --trace-deopt. Bug: v8:9534 Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63330}
-
- 06 Aug, 2019 1 commit
-
-
Jakob Gruber authored
When serializing frame states into translations (later used by deopts), we pass certain values, depending on the frame kind, to be serialized as the frame height. This CL moves the calculation of this height value into the FrameStateDescriptor. In a follow-up, we may want to simplify the way these height values are passed and processed by deopts. The motivation behind this is to simplify calculation of unoptimized stack frame sizes during compilation. Bug: v8:9534 Change-Id: I20d2b57a42cea0c238b9c887dba0280f6aad76de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728609 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63085}
-
- 29 Jul, 2019 3 commits
-
-
Clemens Hammacher authored
This is a reland of 658ff200 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} Bug: v8:9396, v8:7629 Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62959}
-
Clemens Hammacher authored
This reverts commit 658ff200. Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} TBR=yangguo@chromium.org,clemensh@chromium.org Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9396, v8:7629 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62958}
-
Clemens Hammacher authored
We have hundreds of classes that derive from {BitField} without adding any functionality. This CL switches all such occurrences to 'using' declarations instead. Before: class MyBitField : public BitField<int, 6, 4, MyEnum> {}; After: using MyBitField = BitField<int, 6, 4, MyEnum>; This might reduce compilation time by reducing the number of existing classes. The old pattern is forbidden now by making {BitField} final. R=yangguo@chromium.org Bug: v8:9396, v8:7629 Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62956}
-
- 31 May, 2019 1 commit
-
-
Santiago Aboy Solanes authored
CompressedHeapConstant is used in the DecompressionElimination Reducer to create compressed HeapConstant values. It won't appear in the graph up until that point. This CL enables back the disabled tests in DecompressionElimination, as well as generating the CompressedHeapConstant in that reducer. The RelocInfo has already been added for x64 but not for arm64. Therefore, the x64 version is now doing the mov on 32 bits. The support for ARM will come in a following CL, and for now it is doing the mov in 64 bits. 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:9298 Change-Id: If0ca4f937cfa60501679e66f6fd5ded2df38f605 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632236Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#61950}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 15 May, 2019 1 commit
-
-
Yang Guo authored
R=bmeurer@chromium.org, clemensh@chromium.org, jkummerow@chromium.org, sigurds@chromium.org, ulan@chromium.org, verwaest@chromium.org Bug: v8:9247 Change-Id: I153a6bbfc55989fe7a86c052f95c5cb8ee61e841 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613244 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#61557}
-
- 01 Apr, 2019 1 commit
-
-
Sigurd Schneider authored
Bug: v8:9020 Change-Id: If32de05a48bddf5f746b2a3ea810ee350f6a7dda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541051 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60540}
-
- 29 Mar, 2019 2 commits
-
-
Clemens Hammacher authored
Even though both are allowed in the style guide, it recommends to use 'using', as its syntax is more consistent with the rest of C++. This CL turns all typedefs in compiler code to 'using' declarations. R=mstarzinger@chromium.org Bug: v8:8834 Change-Id: I3baf3ecbfe2c853cb17bb479ebbf140382193b5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545896 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60527}
-
Jaroslav Sevcik authored
Bug: v8:8977 Change-Id: I3eed7db62e4b6fc8f8e51c5aca29c8b78439a400 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545891Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#60526}
-
- 13 Mar, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Bug: v8:8977 Change-Id: I3bf6606d9db2369f5d82c71c5f58f6cf0c34bc0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520712 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#60220}
-
- 21 Feb, 2019 1 commit
-
-
Stephan Herhut authored
This change adds two spilling modes: SpillAtDefinition and SpillDeferred. The former is the known spilling mode where we spill at definition. The latter spills only in deferred code regions. This is implemented based on control flow aware allocation and its invariants. The effect is mostly the same as splintering with the exception of forward looking allocation decisions still being impacted by register constraints in deferred code. Change-Id: Ia708e5765dd095196a8127deb2d8bec950d37e04 Reviewed-on: https://chromium-review.googlesource.com/c/1437118Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Stephan Herhut <herhut@chromium.org> Cr-Commit-Position: refs/heads/master@{#59759}
-
- 13 Feb, 2019 1 commit
-
-
Nico Weber authored
For macros expanding to function definitions, I removed the spurious ; after macro invocations. For macros expandign to function declarations, I made the ; required and consistently inserted it. No behavior change. Bug: chromium:926235 Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549 Reviewed-on: https://chromium-review.googlesource.com/c/1467545Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59558}
-
- 28 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
The workaround is simple: cast to unsigned before shifting. Bug: v8:3770 Change-Id: I5f0f7af697ec5db0ab1df3d061008940c83c5c56 Reviewed-on: https://chromium-review.googlesource.com/c/1436215Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#59140}
-
- 15 Jan, 2019 1 commit
-
-
Stephan Herhut authored
The blazor benchmark wobbles around by 5% with seemingly unrelated changes to the generated code. I suspect this is due to moving target adresses of the switch statement for the interpreter. Generally, it would make sense to align targets for switch statements as per general optimization guidelines. To keep code growth in bounds, this change only enables this for switch statements inside of loops. Local measurements show an improvement of around 5% for blazor and hopefully the benchmark will be more stable moving forward. Bug: chromium:919986 chromium:921477 Change-Id: I69df38f902d4fcc65af9e95a63ca1f7f14e0fa09 Reviewed-on: https://chromium-review.googlesource.com/c/1411637Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Stephan Herhut <herhut@chromium.org> Cr-Commit-Position: refs/heads/master@{#58825}
-
- 27 Dec, 2018 1 commit
-
-
Clemens Hammacher authored
They will later be detected as redundant again, but we can save memory and performance by just not adding them in the first place. R=mvstanton@chromium.org Bug: v8:8423 Change-Id: I11d88642333681612e2f8f4eaee7ba700cbf64d5 Reviewed-on: https://chromium-review.googlesource.com/c/1390132Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58479}
-
- 19 Dec, 2018 1 commit
-
-
Sigurd Schneider authored
This refactoring reduces the LoC after preprocessor expansion by 370,322 gen ( 21 files): 71,503 to 1,631,168 ( 23x) src ( 624 files): 367,639 to 53,231,764 ( 145x) test ( 392 files): 490,770 to 37,450,839 ( 76x) third_party ( 432 files): 239,085 to 9,547,902 ( 40x) total ( 1521 files): 1,183,681 to 102,836,194 ( 87x) gen ( 21 files): 71,503 to 1,613,222 ( 23x) src ( 624 files): 367,634 to 52,964,046 ( 144x) test ( 392 files): 490,771 to 37,366,181 ( 76x) third_party ( 432 files): 239,085 to 9,547,902 ( 40x) total ( 1521 files): 1,183,677 to 102,465,872 ( 87x) Bug: v8:8562 Change-Id: Ib4e771c37471a2ff19c5538e62c038943cc74eaf Reviewed-on: https://chromium-review.googlesource.com/c/1382469Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58349}
-
- 22 Nov, 2018 1 commit
-
-
Clemens Hammacher authored
Remove PrintableInstructionSequence and friends, just overload operator<< directly for the respective types. R=herhut@chromium.org Bug: v8:8238 Change-Id: I67713978ab06f7ec5309e52b4090256480f362b1 Reviewed-on: https://chromium-review.googlesource.com/c/1346113Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Stephan Herhut <herhut@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57722}
-
- 21 Nov, 2018 1 commit
-
-
Clemens Hammacher authored
Register names are static, so we do not need to access them via RegisterConfiguration. This saves a lot of RegisterConfiguration object creations. R=mstarzinger@chromium.org Bug: v8:8238 Change-Id: I295ad4d4b13fe948c70490687b7e3e9b48e70af9 Reviewed-on: https://chromium-review.googlesource.com/c/1342517Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57668}
-
- 16 Nov, 2018 1 commit
-
-
Ben L. Titzer authored
This CL implements an assembly order optimization that moves blocks that end a loop with an unconditional backedge to the beginning of the loop, saving a branch. R=jarin@chromium.org,mstarzinger@chromium.org BUG=v8:8423 Change-Id: I8a5d25f5472d71227af0f623277ea8d0a8d69867 Reviewed-on: https://chromium-review.googlesource.com/c/1335944 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57572}
-
- 12 Nov, 2018 1 commit
-
-
Ben L. Titzer authored
This CL splits the backend of TurboFan off into its own directory, without changing namespaces. This makes ownership management a bit more fine-grained with a logical separation. R=mstarzinger@chromium.org,jarin@chromium.org,adamk@chromium.org Change-Id: I2ac40d6ca2c4f04b8474b630aae0286ecf79ef42 Reviewed-on: https://chromium-review.googlesource.com/c/1308333 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57437}
-
- 17 Oct, 2018 1 commit
-
-
Jaroslav Sevcik authored
Bug: chromium:895799 Change-Id: Icbc06f1fc2362a04e76961f50a8ba4b29080837c Reviewed-on: https://chromium-review.googlesource.com/c/1286336Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56720}
-
- 21 Sep, 2018 1 commit
-
-
Jakob Kummerow authored
GCC 7.x doesn't like it (-Werror=subobject-linkage) when a class either derives from a class or has a member field of a type that was declared in an anonymous namespace. It is also opposed (-Werror=attributes) to visibility attributes being defined at explicit template instantiations. GCC 8.x further has reservations (-Werror=class-memaccess) about letting memset/memcpy modify areas within non-POD objects. Change-Id: Ic5107bb5ee3af6233e3741e3ef78d03a0a84005a Reviewed-on: https://chromium-review.googlesource.com/1208306 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56106}
-
- 19 Sep, 2018 1 commit
-
-
Maya Lekova authored
This CL implements the following design doc: https://docs.google.com/document/d/1h5kdfemMQMpUd15PSKW1lqikJW5hsGwrmOvoqhGFRts/edit?ts=5b978756#heading=h.urs7r34mx9p Bug: v8:7790 Change-Id: I5f758c6d906ea9275c30b28f339063c64a2dc8d8 Reviewed-on: https://chromium-review.googlesource.com/1221807Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56021}
-
- 17 Sep, 2018 1 commit
-
-
Florian Sattler authored
Fixing clang-tidy warning. Bug: v8:8015 Change-Id: I7d885f0e2ba3cdf97de190166dc4cdd24dc0c11e Reviewed-on: https://chromium-review.googlesource.com/1224091 Commit-Queue: Florian Sattler <sattlerf@google.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#55956}
-
- 30 Aug, 2018 1 commit
-
-
Bill Budge authored
- Cleans up existing code that tests for representations using a bitmask. - Bypass FP register allocation for sequences without FP vregs. Change-Id: I5ff32e80e0c33848ba83ee17f786b01e37821aa2 Reviewed-on: https://chromium-review.googlesource.com/1195528 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#55535}
-
- 26 Jul, 2018 1 commit
-
-
Deepti Gandluri authored
Change-Id: I9cab4e35c356a1fdd9942bd54832e7a375cd0800 Reviewed-on: https://chromium-review.googlesource.com/1152162Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#54739}
-
- 15 Mar, 2018 1 commit
-
-
Benedikt Meurer authored
This makes the moves from constants to the poisoning register explicit so that the register allocator does not have to burn a register on it. Bug: chromium:798964, chromium:820726, v8:7503, v8:7518 Change-Id: Ifc8f9a2f685405dd38fec583bb0e20c3f0320903 Reviewed-on: https://chromium-review.googlesource.com/964202Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51963}
-