- 23 Dec, 2019 1 commit
-
-
Tobias Tebbi authored
This enables using the GraphAssembler for Wasm. Change-Id: Id1f46db6cc05c9de6e878fb062434211a9c390ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977160 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#65552}
-
- 24 Oct, 2019 1 commit
-
-
Ross McIlroy authored
This rearranges the TurboProp pipeline to avoid the need for a second schedule of the graph. To do this, it moves the final schedule creation before effect-control-linearization (which used a temporary schedule previously, and with TurboFan). It then enables the block updater in the graph assembler for effect control linearization and does select and memory lowering in a new ScheduledMachineLowering phase to maintain this existing schedule during these lowering passes. BUG=v8:9684 Change-Id: I6a7790b010f8b152dd01d85aa95ee5d4f99087a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847351 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64537}
-
- 25 Sep, 2019 1 commit
-
-
Ross McIlroy authored
Seperates the memory lowering operations into a seperate MemoryLowering class which is used by the MemoryOptimizer. This will enable TurboProp to reduce memory operations without having to do a full memory optimization pass. BUG=v8:9684 Change-Id: I1b333f1360fd342612672842bf879f44ab1ee60c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1815243Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63966}
-
- 01 Aug, 2019 1 commit
-
-
Michael Starzinger authored
This removes the explicit {kCallWithCallerSavedRegisters} opcode which is just a regular call node with special handling for saving/restoring caller saved registers before/after the call. This is now handled via the {CallDescriptor::kCallerSavedRegisters} flag. R=neis@chromium.org BUG=v8:9396 Change-Id: Ie6421085eb2be8a067040222cd5215a9b1013048 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728611Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63021}
-
- 26 Jul, 2019 1 commit
-
-
Santiago Aboy Solanes authored
The propagation of tenuring from outer allocations to inner allocations was blocked in pointer compression since we now had Compress nodes between AllocateRaw and StoreField. This was causing issues in GC. It popped up in the Octane2.1/Splay benchmark, where we had big regressions. This CL updates the memory optimizer so that it can use the Compress nodes as bridges and can perform the optimization successfully. Note that the Compress nodes only appear on the value input of the StoreField. 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:7703, v8:9519 Change-Id: I6b0cc67955c6cc696e8c426b85c87a1794098ed0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714650Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#62938}
-
- 17 Jul, 2019 1 commit
-
-
Tobias Tebbi authored
This adds a simple counter to Turbofan that's incremented throughout the compilation, hopefully frequently enough so we can use it to detect divergence and performance bugs. In addition, we assert that this counter never gets too high. That's the equivalent of a simple timeout, just more deterministic. The limitations on Turbofan input size should guarantee that we never exceed this limit. Since we probably do exceed it rarely, this check is only a DCHECK and intended to detect performance and divergence issues, but not supposed to be performed in release builds. In addition, this CL adds UMA stats to observe the real world distribution of the tick measurement. Bug: v8:9444 Change-Id: I182dac6ecac64715e3f5885ff5c7c17549351cd0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695475 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#62754}
-
- 28 May, 2019 1 commit
-
-
Georg Schmid authored
R=tebbi@chromium.org Change-Id: I30aab2663180382a078901c10e39cd1ad6c906f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627541 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61897}
-
- 15 May, 2019 1 commit
-
-
Tobias Tebbi authored
With very few exceptions, this verifies all skipped write-barriers in CSA and Torque, showing that the MemoryOptimizer together with some type information on the stored value are enough to avoid unsafe skipped write-barriers. Changes to CSA: SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the MemoryOptimizer by default. Type information about the stored values (TNode<Smi>) is exploited to safely skip write barriers for stored Smi values. In some cases, the code is re-structured to make it easier to consume for the MemoryOptimizer (manual branch and load elimination). Changes to the MemoryOptimizer: Improve the MemoryOptimizer to remove write barriers: - When the store happens to a CSA-generated InnerAllocate, by ignoring Bitcasts and additions. - When the stored value is the HeapConstant of an immortal immovable root. - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned). - Fast C-calls are treated as non-allocating. - Runtime calls can be white-listed as non-allocating. Remaining missing cases: - C++-style iterator loops with inner pointers. - Inner allocates that are reloaded from a field where they were just stored (for example an elements backing store). Load elimination would fix that. - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole). We could handle that in Torque. - Double-aligned allocations, which are not lowered in the MemoryOptimizer but in CSA. Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this can be handled by overload resolution (in Torque and C++). Reland Change: Support pointer compression operands. R=jarin@chromium.org TBR=mvstanton@chromium.org Bug: v8:7793 Change-Id: I84e1831eb6bf9be14f36db3f8b485ee4fab6b22e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612904 Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61522}
-
- 26 Apr, 2019 1 commit
-
-
Ross McIlroy authored
This reverts commit da7322c0. Reason for revert: Breaking the pointer compression bots, e.g.: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3047 Original change's description: > [csa] verify skipped write-barriers in MemoryOptimizer > > With very few exceptions, this verifies all skipped write-barriers in > CSA and Torque, showing that the MemoryOptimizer together with some > type information on the stored value are enough to avoid unsafe skipped > write-barriers. > > Changes to CSA: > SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the > MemoryOptimizer by default. > Type information about the stored values (TNode<Smi>) is exploited to > safely skip write barriers for stored Smi values. > In some cases, the code is re-structured to make it easier to consume > for the MemoryOptimizer (manual branch and load elimination). > > Changes to the MemoryOptimizer: > Improve the MemoryOptimizer to remove write barriers: > - When the store happens to a CSA-generated InnerAllocate, by ignoring > Bitcasts and additions. > - When the stored value is the HeapConstant of an immortal immovable root. > - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned). > - Fast C-calls are treated as non-allocating. > - Runtime calls can be white-listed as non-allocating. > > Remaining missing cases: > - C++-style iterator loops with inner pointers. > - Inner allocates that are reloaded from a field where they were just stored > (for example an elements backing store). Load elimination would fix that. > - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole). > We could handle that in Torque. > - Double-aligned allocations, which are not lowered in the MemoryOptimizer > but in CSA. > > Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this > can be handled by overload resolution (in Torque and C++). > > R=jarin@chromium.org > TBR=mvstanton@chromium.org > > Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61016} TBR=mvstanton@chromium.org,jarin@chromium.org,tebbi@chromium.org Change-Id: I36877cd6d08761726ef8dce8a3e3f2ce3eebe6cf No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585732Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#61038}
-
- 25 Apr, 2019 1 commit
-
-
Tobias Tebbi authored
With very few exceptions, this verifies all skipped write-barriers in CSA and Torque, showing that the MemoryOptimizer together with some type information on the stored value are enough to avoid unsafe skipped write-barriers. Changes to CSA: SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the MemoryOptimizer by default. Type information about the stored values (TNode<Smi>) is exploited to safely skip write barriers for stored Smi values. In some cases, the code is re-structured to make it easier to consume for the MemoryOptimizer (manual branch and load elimination). Changes to the MemoryOptimizer: Improve the MemoryOptimizer to remove write barriers: - When the store happens to a CSA-generated InnerAllocate, by ignoring Bitcasts and additions. - When the stored value is the HeapConstant of an immortal immovable root. - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned). - Fast C-calls are treated as non-allocating. - Runtime calls can be white-listed as non-allocating. Remaining missing cases: - C++-style iterator loops with inner pointers. - Inner allocates that are reloaded from a field where they were just stored (for example an elements backing store). Load elimination would fix that. - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole). We could handle that in Torque. - Double-aligned allocations, which are not lowered in the MemoryOptimizer but in CSA. Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this can be handled by overload resolution (in Torque and C++). R=jarin@chromium.org TBR=mvstanton@chromium.org Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61016}
-
- 29 Mar, 2019 1 commit
-
-
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}
-
- 12 Mar, 2019 1 commit
-
-
Hannes Payer authored
Bug: v8:8945 Change-Id: I14ca4b29f1b12ff95e718d431f65d88ab1238c53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511478Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60177}
-
- 05 Feb, 2019 1 commit
-
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: Ic7a719eb9216d848d7148e4eb8a239c1637e0bb5 Reviewed-on: https://chromium-review.googlesource.com/c/1430064Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59368}
-
- 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}
-
- 14 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
This adds support to TurboFan's representation selection for the Word64 representation, and makes use of that to handle indices for memory access and allocation instructions (i.e. LoadElement, StoreElement, Allocate, etc.). These instructions had previously used Word32 as representation for the indices / sizes, and then internally converted it to the correct representation (aka Word64 on 64-bit architectures) later on, but that was kind of brittle, and sometimes led to weird generated code. The change thus only adds support to convert integer values in the safe integer range from all kinds of representations to Word64 (on 64-bit architectures). We don't yet handle the opposite direction and none of the representation selection heuristics for the numeric operations were changed so far. This will be done in follow-up CLs. This CL itself is supposed to be neutral wrt. functionality, and only serves as a starting point, and a cleanup for the (weird) implicit Word64 index/size handling. Bug: v8:7881, v8:8015, v8:8171 Design-Document: http://bit.ly/turbofan-word64 Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel Reviewed-on: https://chromium-review.googlesource.com/1224932 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#55886}
-
- 30 Apr, 2018 1 commit
-
-
Jaroslav Sevcik authored
The idea is to mark all the branches and loads participating in array bounds checks, and let them contribute-to/use the poisoning register. In the code, the marks for array indexing operations now contain "Critical" in their name. By default (--untrusted-code-mitigations), we only instrument the "critical" operations with poisoning. With that in place, we also remove the array masking approach based on arithmetic. Since we do not propagate the poison through function calls, we introduce a node for poisoning an index that is passed through function call - the typical example is the bounds-checked index that is passed to the CharCodeAt builtin. Most of the code in this CL is threads through the three levels of protection (safe, critical, unsafe) for loads, branches and flags. Bug: chromium:798964 Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b Reviewed-on: https://chromium-review.googlesource.com/995413 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52883}
-
- 27 Mar, 2018 1 commit
-
-
Tobias Tebbi authored
This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
-
- 21 Mar, 2018 1 commit
-
-
Hannes Payer authored
Change-Id: If8678bd244a0a4e21b1967c15da80e49643a33ea Reviewed-on: https://chromium-review.googlesource.com/973001Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52101}
-
- 05 Mar, 2018 1 commit
-
-
Jaroslav Sevcik authored
Change-Id: I618e357ea0d00b64dd4d8a54e865bed716a460e8 Bug: chromium:798964 Reviewed-on: https://chromium-review.googlesource.com/947963Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#51716}
-
- 10 Nov, 2017 1 commit
-
-
Mike Stanton authored
This is a reland of ba76ad68 Original change's description: > [Turbofan] Introduce AllocateRaw node > > In order to simplify and verify the TurboFan graph, we > need to wire allocations into the control chain after > effect control linearization. > > Bug: v8:7002 > Change-Id: I4c5956c8d16773d721482d46a0b407bee01a9597 > Reviewed-on: https://chromium-review.googlesource.com/738139 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49209} TBR=jarin@chromium.org Bug: v8:7002 Change-Id: Iba588c498bb5de113abfba7f9e40cfe4325dea4a Reviewed-on: https://chromium-review.googlesource.com/758436 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#49300}
-
- 08 Nov, 2017 2 commits
-
-
Michael Stanton authored
This reverts commit ba76ad68. Reason for revert: Broke GCStress on arm64 port...investigating Original change's description: > [Turbofan] Introduce AllocateRaw node > > In order to simplify and verify the TurboFan graph, we > need to wire allocations into the control chain after > effect control linearization. > > Bug: v8:7002 > Change-Id: I4c5956c8d16773d721482d46a0b407bee01a9597 > Reviewed-on: https://chromium-review.googlesource.com/738139 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49209} TBR=mvstanton@chromium.org,jarin@chromium.org Change-Id: I98669fdff1b960912d6eaad239776262f7bf8c67 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7002 Reviewed-on: https://chromium-review.googlesource.com/758396Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#49212}
-
Mike Stanton authored
In order to simplify and verify the TurboFan graph, we need to wire allocations into the control chain after effect control linearization. Bug: v8:7002 Change-Id: I4c5956c8d16773d721482d46a0b407bee01a9597 Reviewed-on: https://chromium-review.googlesource.com/738139Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#49209}
-
- 21 Aug, 2017 1 commit
-
-
Albert Mingkun Yang authored
The new node behave the same as its counterpart, CallCFunction, with the additional saving and restoring caller saved registers before and after the function call. Bug: chromium:749486 Change-Id: I0a1dfb2e4e55f7720541a00e6d16fd20220f39ed Reviewed-on: https://chromium-review.googlesource.com/620709 Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47479}
-
- 03 Jan, 2017 1 commit
-
-
jarin authored
Review-Url: https://codereview.chromium.org/2602413002 Cr-Commit-Position: refs/heads/master@{#42041}
-
- 20 Sep, 2016 1 commit
-
-
heimbuef authored
This is some initial cleanup to keep /src clean. The AccountingAllocator is actually exclusively used by zones and this common subfolder makes that more clear. BUG=v8:5409 Review-Url: https://codereview.chromium.org/2344143003 Cr-Commit-Position: refs/heads/master@{#39558}
-
- 10 May, 2016 1 commit
-
-
bmeurer authored
This adds a new pass MemoryOptimizer that walks over the effect chain from Start and lowers all Allocate, LoadField, StoreField, LoadElement, and StoreElement nodes, trying to fold allocations into allocation groups and eliminate write barriers on StoreField and StoreElement if possible (i.e. if the object belongs to the current allocation group and that group allocates in new space). R=hpayer@chromium.org, jarin@chromium.org BUG=v8:4931, chromium:580959 LOG=n Review-Url: https://codereview.chromium.org/1963583004 Cr-Commit-Position: refs/heads/master@{#36128}
-