- 30 Oct, 2019 1 commit
-
-
Jakob Gruber authored
This is a reland of 4a16305b The original CL adjust only one part of the stack check, namely the comparison of the stack pointer against the stack limit in generated code. There is a second part: Runtime::kStackGuard repeats this check to distinguish between a stack overflow and an interrupt request. This second part in runtime must apply the offset just like in generated code. It is implemented in this reland by the StackCheckOffset operator and a new StackGuardWithGap runtime function. Original change's description: > [compiler] Optionally apply an offset to stack checks > > The motivation behind this change is that the frame size of an optimized > function and its unoptimized version may differ, and deoptimization > may thus trigger a stack overflow. The solution implemented in this CL > is to optionally apply an offset to the stack check s.t. the check > becomes 'sp - offset > limit'. The offset is applied to stack checks at > function-entry, and is set to the difference between the optimized and > unoptimized frame size. > > A caveat: OSR may not be fully handled by this fix since we've already > passed the function-entry stack check. A possible solution would be to > *not* skip creation of function-entry stack checks for inlinees. > > This CL: 1. annotates stack check nodes with the stack check kind, where > kind is one of {function-entry,iteration-body,unknown}. 2. potentially > allocates a temporary register to store the result of the 'sp - offset' > in instruction selection (and switches input registers to 'unique' > mode). 3. Applies the offset in code generation. > > Drive-by: Add src/compiler/globals.h for compiler-specific globals. > > Bug: v8:9534,chromium:1000887 > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63701} Bug: v8:9534, chromium:1000887 Change-Id: I71771c281afd7d57c09aa48ea1b182d01e6dee2a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822037Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64634}
-
- 25 Oct, 2019 1 commit
-
-
Michael Starzinger authored
This class used to describe unoptimized but compiled frames. All such frames are by now covered via the architecture-independent description in the {StandardFrameConstants} class (or one of its subclasses). R=clemensb@chromium.org BUG=v8:9810 Change-Id: I294cc6eec7d4a05e88e7aa336f1ebedfa0eb6e98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878708Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64556}
-
- 16 Oct, 2019 1 commit
-
-
Sathya Gunasekaran authored
Updates CSA::TryToIntptr to handle array indices that are less than INT_MAX which allows to handle string keys in the ICs. Updates ICs to go monomorphic for string keys that are array indices. Updates Turbofan to handle array indices when lowering element access. Change-Id: Ibdde20130e075d0d645ab4a8266a968335eaad84 Bug: v8:9449 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813018Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64320}
-
- 11 Oct, 2019 1 commit
-
-
Jakob Kummerow authored
This is for consistency and compiler-enforced type safety. No change in behavior intended. Change-Id: I31467832ba6c63fd5f97df9fee6221559b283d67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852766 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64244}
-
- 30 Sep, 2019 2 commits
-
-
Vasili Skurydzin authored
prepare for ptr compression Change-Id: Ia459ad18a30fbfd8e51bd99735f0d63644d30b8f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1831788Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#64051}
-
Milad Farazmand authored
Port 559a0034 Original Commit Message: We didn't think this affected arm but it turns out it does. This is a port of https://chromium-review.googlesource.com/c/v8/v8/+/1688049 R=petermarshall@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Id081736420a20216cef5c5f483acd987785c4d97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1829899Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#64044}
-
- 27 Sep, 2019 4 commits
-
-
Peter Marshall authored
We didn't think this affected arm but it turns out it does. This is a port of https://chromium-review.googlesource.com/c/v8/v8/+/1688049 Bug: v8:9057 Change-Id: I671737107e589673fc32c5fa1760d887d1bcc240 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826665Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64024}
-
Mythri A authored
This is a reland of cfb10028 with a fix for failures in lite mode. Original change's description: > [compiler] Cache OSR optimized code > > With lazy feedback allocation, for functions that get OSRed we may > not have feedback for the initial part of the functions since feedback > vectors might be allocated after the function started executing. Hence > we would not be able to optimize the function on the next call. This > means we may have to OSR twice before we actually optimize function. > This cl introduces OSR cache, so we could reuse the optimized code. One > side effect of this cl is that the OSRed code won't be function context > specialized anymore. > > Bug: chromium:987523 > Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64014} Bug: chromium:987523 Change-Id: I9c782242b07b24d15247533ab4ee044334b429ff TBR: rmcilroy@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826898 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64023}
-
Michael Achenbach authored
This reverts commit cfb10028. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/6483 Original change's description: > [compiler] Cache OSR optimized code > > With lazy feedback allocation, for functions that get OSRed we may > not have feedback for the initial part of the functions since feedback > vectors might be allocated after the function started executing. Hence > we would not be able to optimize the function on the next call. This > means we may have to OSR twice before we actually optimize function. > This cl introduces OSR cache, so we could reuse the optimized code. One > side effect of this cl is that the OSRed code won't be function context > specialized anymore. > > Bug: chromium:987523 > Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64014} TBR=rmcilroy@chromium.org,neis@chromium.org,mythria@chromium.org Change-Id: Ib3692e7570bed5d3e88ca8a0247b185d70497a04 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:987523 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826668Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#64015}
-
Mythri A authored
With lazy feedback allocation, for functions that get OSRed we may not have feedback for the initial part of the functions since feedback vectors might be allocated after the function started executing. Hence we would not be able to optimize the function on the next call. This means we may have to OSR twice before we actually optimize function. This cl introduces OSR cache, so we could reuse the optimized code. One side effect of this cl is that the OSRed code won't be function context specialized anymore. Bug: chromium:987523 Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64014}
-
- 19 Sep, 2019 1 commit
-
-
Jakob Gruber authored
This CL allows us to distinguish between the host- and target OS. The host OS is defined by V8_OS_ macros (e.g. V8_OS_WIN). The target OS is defined by V8_TARGET_OS_ macros (e.g. V8_TARGET_OS_WIN). V8_TARGET_OS_ macros are defined by gn, based on the `target_os` gn variable. If a V8_TARGET_OS_ is set, we also define V8_HAVE_TARGET_OS (this determines fall-back behavior in V8; if it is not defined, we set V8_TARGET_OS_ to equal the equivalent V8_OS_ define). Besides adding the defines, this CL also adds logic to consider the target OS in codegen. Specifically, x64 builds now look at the V8_TARGET_OS_WIN define instead of V8_OS_WIN or _WIN64. This effectively makes cross-compilation to x64 Windows in mksnapshot possible. In future work, we could add similar support for cross-compiling to other platforms such as ia32 Windows. Bug: v8:9736,chromium:803591 Change-Id: I689f3de8c206b743c4bef703f5ade0bba32ce995 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809374Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63892}
-
- 16 Sep, 2019 1 commit
-
-
Georg Neis authored
We used to have two special cases for named accesses on the global proxy, one based on seeing the global proxy constant in the graph and on based on seeing the global proxy map either in the feedback or in the graph. A change I made a while ago accidentally disabled the second one. This CL restores that. Moreover, given how things are set up now (this might have been different before), the first optimization is subsumed by the second one, so this CL also removes the first one. Finally, this CL records an accumulator hint in the case of a load, which improves precision of the serializer for concurrent inlining. Tbr: tebbi@chromium.org Bug: v8:7790 Change-Id: I255afc6c79e5c5c900b3ccfcd8459d836d21e42b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1801954 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#63806}
-
- 13 Sep, 2019 1 commit
-
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:9396 Change-Id: I3233a311e2ee56d9874365eb898a3316622ff6d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/997452Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63750}
-
- 12 Sep, 2019 2 commits
-
-
Jakob Gruber authored
This reverts commit 4a16305b. Reason for revert: Need to revalidate assumptions behind the CHECK. Original change's description: > [compiler] Optionally apply an offset to stack checks > > The motivation behind this change is that the frame size of an optimized > function and its unoptimized version may differ, and deoptimization > may thus trigger a stack overflow. The solution implemented in this CL > is to optionally apply an offset to the stack check s.t. the check > becomes 'sp - offset > limit'. The offset is applied to stack checks at > function-entry, and is set to the difference between the optimized and > unoptimized frame size. > > A caveat: OSR may not be fully handled by this fix since we've already > passed the function-entry stack check. A possible solution would be to > *not* skip creation of function-entry stack checks for inlinees. > > This CL: 1. annotates stack check nodes with the stack check kind, where > kind is one of {function-entry,iteration-body,unknown}. 2. potentially > allocates a temporary register to store the result of the 'sp - offset' > in instruction selection (and switches input registers to 'unique' > mode). 3. Applies the offset in code generation. > > Drive-by: Add src/compiler/globals.h for compiler-specific globals. > > Bug: v8:9534,chromium:1000887 > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63701} TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org Change-Id: Iebf46d5256b6dee13451741781ef85a5fe9b1628 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9534, chromium:1000887 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800565Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63706}
-
Jakob Gruber authored
The motivation behind this change is that the frame size of an optimized function and its unoptimized version may differ, and deoptimization may thus trigger a stack overflow. The solution implemented in this CL is to optionally apply an offset to the stack check s.t. the check becomes 'sp - offset > limit'. The offset is applied to stack checks at function-entry, and is set to the difference between the optimized and unoptimized frame size. A caveat: OSR may not be fully handled by this fix since we've already passed the function-entry stack check. A possible solution would be to *not* skip creation of function-entry stack checks for inlinees. This CL: 1. annotates stack check nodes with the stack check kind, where kind is one of {function-entry,iteration-body,unknown}. 2. potentially allocates a temporary register to store the result of the 'sp - offset' in instruction selection (and switches input registers to 'unique' mode). 3. Applies the offset in code generation. Drive-by: Add src/compiler/globals.h for compiler-specific globals. Bug: v8:9534,chromium:1000887 Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63701}
-
- 09 Sep, 2019 1 commit
-
-
Dominik Inführ authored
Slots are always valid inside an invalidated area when outside the respective object's current size. This allows us to remove the size from the InvalidatedSlots data structure. This change was enabled by https://crrev.com/c/1771793. Reland after revert in https://crrev.com/c/1783106, this CL was not the culprit of the issue (chromium:1000404). Bug: v8:9454 Change-Id: I823d34670515924bf74200daa21a834044087310 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787431Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#63607}
-
- 03 Sep, 2019 1 commit
-
-
Dominik Inführ authored
This reverts commit 93063ade. Reason for revert: Clusterfuzz found issue. Original change's description: > [heap] Remove size from invalidated slots > > Slots are always valid inside an invalidated area when outside the > respective object's current size. This allows us to remove the size > from the InvalidatedSlots data structure. > > This change was enabled by https://crrev.com/c/1771793. > > Bug: v8:9454 > Change-Id: I2b5a7234d47227cb6ad8d67de20e9b5a2028ae83 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773242 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63510} TBR=ulan@chromium.org,sigurds@chromium.org,tebbi@chromium.org,dinfuehr@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9454 Change-Id: I7daf96cf50aaedd4dbdab48fd550182df94e54bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783106Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#63535}
-
- 02 Sep, 2019 1 commit
-
-
Dominik Inführ authored
Slots are always valid inside an invalidated area when outside the respective object's current size. This allows us to remove the size from the InvalidatedSlots data structure. This change was enabled by https://crrev.com/c/1771793. Bug: v8:9454 Change-Id: I2b5a7234d47227cb6ad8d67de20e9b5a2028ae83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773242Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#63510}
-
- 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}
-
- 20 Aug, 2019 2 commits
-
-
Leszek Swirski authored
Since the mutability of HeapNumbers is determined by their owning object's descriptor array, we can remove the MutableHeapNumber type entirely, at the cost of a few fewer DCHECKs and a couple of TODOs to use the descriptor array information. This is a necessary step towards a follow-up which allows in-place Double -> Tagged transitions Design doc: https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/ Bug: v8:9606 Change-Id: I13209f9c86f1f204088f6fd80089e17d956b4a50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743972 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63294}
-
Jakob Gruber authored
The deoptimizer calculates frame layout based on the translation's `height` field, together with additional data (e.g.: are we looking at the topmost frame? what kind of deopt are we in?). The result is the final deoptimized frame size in bytes, together with a bunch of intermediate results such as the variable frame size (= without the fixed-size portion). In order to consider the deoptimized frame size in optimized stack checks, we will need to calculate the frame layout during compilation in addition to what we currently do during deoptimization. This CL moves in that direction by extracting relevant parts of frame layout calculation into classes that can be reused by both compiler and deoptimizer. These helpers will support both precise and conservative modes; the deoptimizer will use the precise mode (since it has full information), while the instruction selector will use the conservative mode. Bug: v8:9534 Change-Id: I93d6c39f10d251733f4625d3cc161b2010652d02 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760825 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63279}
-
- 19 Aug, 2019 2 commits
-
-
Jakob Gruber authored
DoComputeInterpretedFrame and friends are long and complex functions. It is often not clear which variables are constants and which are later modified. This CL tries to clarify, mostly by marking variables const when possible. Bug: v8:9534 Change-Id: Ifa73402c392ad244ab5ea37262293f8d9db98be0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752848 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63245}
-
Jakob Gruber authored
Information required for deoptimization is passed from codegen to the deoptimizer through so-called translations. Translations contain, among many other things, a 'height' field. It is used during deopts to calculate the unoptimized frame height (but note that it does not correspond exactly to the frame height itself - further calculations on the deopt side are needed to get to the real frame height). The height field has roughly the following data flow: 1. During codegen, we serialize whatever FrameStateDescriptor::GetHeight() returns. 2. During deopts, serialized translations are converted into TranslatedFrame objects in TranslatedState::CreateNextTranslatedFrame. 3. These are later used to arrive at the real frame height in multiple spots, e.g. in DoComputeInterpretedFrame and friends. Prior to this CL, we were adding and subtracting 1 in basically random spots. For example, for interpreted and construct stub frames we added 1 in step 1 and subtracted 1 in step 3. For continuation frames, we added 1 in step 2 and subtracted it in step 3. Argument adaptor frames were left untouched. This CL removes all these +-1's. The height field now contains locals_count() for interpreted frames, and parameters_count() for everything else. I also tried to make the meaning of adds/subs clearer through use of named constants like kTheReceiver. Bug: v8:9534 Change-Id: I6fd26886ff5aa63930f413d879d5480578d9dc7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751724Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63238}
-
- 13 Aug, 2019 1 commit
-
-
Jakob Gruber authored
This reverts commit 47e077a2. Reason for revert: To avoid hard crashes on this CHECK until a proper fix has landed. Original change's description: > [deoptimizer] Check whether output frames fit into stack space > > Change-Id: I7af0fe843f73b702b03ffa50ecca19aabd7583b8 > Bug: chromium:983850 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701858 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62738} TBR=neis@chromium.org,sigurds@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:983850,chromium:987930,v8:9534 Change-Id: I1f1fe76c957e1f1cf2a117a5ddc7e62004497aeb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741665Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63186}
-
- 02 Aug, 2019 1 commit
-
-
Milad Farazmand authored
Trying to use double_registers for fetching single precision fp values creates four different implementations of this method depending on the architecture, hence separating them out into their respective folder. Change-Id: Ide61fe2e7a95bd8427b377959b262633d8c57e61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730663Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#63042}
-
- 31 Jul, 2019 2 commits
-
-
Milad Farazmand authored
Port 556e4859 Original Commit Message: Instead of storing the values of the single precision floating point registers, get their values from the aliased double precision registers. This saves, on arm64, 184 bytes per deoptimisation kind function (552 in total) and 128 bytes in the RegisterValues class. R=joey.gouly@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: If38a721cfaefb7980902f4f963119cb88061e342 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726857Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#63006}
-
Yu Yin authored
port 556e4859 https://crrev.com/c/1669687 Original Commit Message: Instead of storing the values of the single precision floating point registers, get their values from the aliased double precision registers. This saves, on arm64, 184 bytes per deoptimisation kind function (552 in total) and 128 bytes in the RegisterValues class. Change-Id: Ic178de717d27a63b3f510b3a93e8f33a1730dc8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725669Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yu Yin <xwafish@gmail.com> Cr-Commit-Position: refs/heads/master@{#62998}
-
- 30 Jul, 2019 1 commit
-
-
Georgia Kouveli authored
Do not pass the deoptimization index in a register, instead infer it from the address we made the deoptimization call from. This makes the deoptimization exit sequence one instruction long instead of two. This requires emitting all deoptimization exits at the end of the function in a contiguous block, making sure no constant or veneer pools are emitted in between. This means that soft deoptimizations require an additional branch to the end of the function, which counteracts the removal of the move instruction, however soft deoptimizations are rare compared to eager and lazy ones. This reduces the code size of optimised functions for benchmarks like Octane and ARES-6 by about 4%. Change-Id: I771f9104a07de7931a4bb9c5836e25fb55b1a2a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714876 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62991}
-
- 29 Jul, 2019 1 commit
-
-
Joey Gouly authored
Instead of storing the values of the single precision floating point registers, get their values from the aliased double precision registers. This saves, on arm64, 184 bytes per deoptimisation kind function (552 in total) and 128 bytes in the RegisterValues class. Change-Id: I681ad46efbb610e94d1e45871e012d2c0a3cfa3b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669687 Commit-Queue: Martyn Capewell <martyn.capewell@arm.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62961}
-
- 17 Jul, 2019 1 commit
-
-
Jiayao Lin authored
Change-Id: I8034f64ba412a7d880fdc1b7bc4dce0b41fe3114 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1696915Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#62786}
-
- 16 Jul, 2019 1 commit
-
-
Sigurd Schneider authored
Change-Id: I7af0fe843f73b702b03ffa50ecca19aabd7583b8 Bug: chromium:983850 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701858 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62738}
-
- 12 Jul, 2019 1 commit
-
-
Peter Marshall authored
Everyone was getting a copy of this through debug.h. Bug: v8:9396 Change-Id: I5189cb4bf27a3381768b0be479d7b3d60dec20bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695472 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62670}
-
- 11 Jul, 2019 2 commits
-
-
Peter Marshall authored
Add a bit on the isolate which indicates that the stack is currently not iterable for the SafeStackFrameIterator. This is needed during deoptimization, when we do a fast C call without a return address on the stack, meaning we can't iterate the stack frames. Re-enable DeoptAtFirstLevelInlinedSource which is fixed by this CL. Bug: v8:9057 Change-Id: I76379a2dd38023be7e6f5153edeb1f838e9ac4d6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688049 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62634}
-
Clemens Hammacher authored
The {msg} argument to Assembler::stop is dead since https://crrev.com/2178093003 (July 2016). This CL removes it. R=mstarzinger@chromium.org Bug: v8:9396 Change-Id: I1593361709ab4977760f1ea21e3008797ef99cab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692925 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62623}
-
- 08 Jul, 2019 4 commits
-
-
Georg Neis authored
Change-Id: Ie0f54dd36a7af9503306d756182d98fc2273b48a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690828 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#62558}
-
Nico Hartmann authored
Feedback shall not be updated by the deoptimizer. Although this mechanism exists, it shall not be used if possible. This CL changes how V8 learns from BigInt deopts: Previously we updated feedback on the BinaryOperations in the deoptimizer, now we let the interpreter widen the feedback type from BigInt to Any after the deopt has occurred. Bug: v8:9407 Change-Id: I92e5e733085b433fd8ab452674d02404b81b2796 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687419Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@google.com> Cr-Commit-Position: refs/heads/master@{#62548}
-
Simon Zünd authored
This CL teaches the deoptimizer about JavaScriptBuiltinContinuation frames that are not preceded by argument adapter frames. This pattern is used when calling C++ API functions from TurboFan. This CL fixes a crash when the deoptimizer encounters the pattern described above. The crash was caused when the deoptimizer tried to read the arguments of the continuation frame. As no adapter frame was present, the argument count was read from the SharedFunctionInfo which had the kDontAdaptArgumentsSentinel value. This translated to an argument count of ~65000 later down the line, which caused a FATAL error when the deoptimizer tried to re-construct ~65000 non-existent values. Bug: chromium:980529 Change-Id: Id2de3bf7607102ab5a16de344c649015e968b185 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687417Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#62547}
-
Georg Neis authored
Change-Id: I9285052dfe21df8e0eaf0e0493458532f82504ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687421Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62546}
-