- 21 May, 2020 8 commits
-
-
Ng Zhi An authored
The proposal uses the lane shape, e.g. i64x2.anytrue, and we were using s1x2.anytrue in our opcodes. This was a legacy naming, because we were trying to bitpack the booleans. Now that we aren't doing that, rename these to be more consistent with the proposal. This was done with a straightforward sed script, changing both cpp code and also some comments in mjsunit test files. Bug: v8:10506 Change-Id: If077ed805de23520d8580d6b3b1906c80f67b94f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207915 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67945}
-
Seth Brenith authored
Currently, if d8 is run with the --turbo-profiling flag, it prints info about every TurboFan-compiled function. This info includes the number of times that each basic block in the function was run. It also includes text representations of the function's schedule and code, so that the person reading the output can associate counters with blocks of code. The data about each function is currently stored in a BasicBlockProfiler::Data instance, which is attached to a list owned by the singleton BasicBlockProfiler. Each Data contains an std::vector<uint32_t> which represents how many times each block in the function has executed. The generated code for each block uses a raw pointer into the storage of that vector to implement incrementing the counter. With this change, if you compile with v8_enable_builtins_profiling and then run with --turbo-profiling, d8 will print that same info about builtins too. In order to generate code that can survive being serialized to a snapshot and reloaded, this change uses counters in the JS heap instead of a std::vector outside the JS heap. The steps for instrumentation are as follows: 1. Between scheduling and instruction selection, add code to increment the counter for each block. The counters array doesn't yet exist at this point, and allocation is disallowed, so at this point the code refers to a special marker value. 2. During finalization of the code, allocate a BasicBlockProfilingData object on the JS heap containing data equivalent to what is stored in BasicBlockProfiler::Data. This includes a ByteArray that is big enough to store the counters for each block. 3. Patch the reference in the BuiltinsConstantsTableBuilder so that instead of referring to the marker object, it now refers to this ByteArray. Also add the BasicBlockProfilingData object to a list that is attached to the heap roots so it can be easily accessed for printing. Because these steps include modifying the BuiltinsConstantsTableBuilder, this procedure is only applicable to builtins. Runtime-generated code still uses raw pointers into std::vector instances. In order to keep divergence between these code paths to a minimum, most work is done referring to instances of BasicBlockProfiler::Data (the C++ class), and functions are provided to copy back and forth between that type and BasicBlockProfilingData (the JS heap object). This change is intended only to make --turbo-profiling work consistently on more kinds of functions, but with some further work, this data could form the basis for: - code coverage info for fuzzers, and/or - hot-path info for profile-guided optimization. Bug: v8:10470, v8:9119 Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67944}
-
Santiago Aboy Solanes authored
Some non-templated uses remain until further TNodification. Bug: v8:9708, v8:6949 Change-Id: Ica841f95a6ddfbdea78589f9db47c5b4126497f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212263 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#67943}
-
Santiago Aboy Solanes authored
Bug: v8:9708, v8:6949 Change-Id: Ia57ba7e0e24f5f402147246981ba1a1c30295abf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212262Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#67942}
-
Santiago Aboy Solanes authored
Bug: v8:9708, v8:6949 Change-Id: I60237b03a474a9d8e30bf48b6d9196a07fb81171 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212261Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1a96233..99ffd3c Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/c8f5482..7a0ebcc Rolling v8/third_party/aemu-linux-x64: wCYE7BPak_YwqYwMPrwRw1mwSyAzsuX3tth_UvhHUEUC..4xEEbuyLmLA-dGdzewQlaM2km7fPUiGEEdIQJhIK8v4C Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/503f81b..ae2ed9f Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/d8c6146..8f6bfe3 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/a0ee3ce..e34638c TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I0d238afaaeec823e1be91bfe7f75e741f622e27e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208123Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#67940}
-
Zhi An Ng authored
This reverts commit 401b5866. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/12753? Original change's description: > [Promise.any] Ship Promise.any > > Bug: v8:9808 > Change-Id: I806e498725dfa1dd312f81cc3b423708ee988a20 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210238 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Auto-Submit: Marja Hölttä <marja@chromium.org> > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67938} TBR=marja@chromium.org,syg@chromium.org Change-Id: I84dd58354b63d5a24dc4af430c068fe2da67bb76 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9808 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211301Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67939}
-
Marja Hölttä authored
Bug: v8:9808 Change-Id: I806e498725dfa1dd312f81cc3b423708ee988a20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210238 Commit-Queue: Shu-yu Guo <syg@chromium.org> Auto-Submit: Marja Hölttä <marja@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#67938}
-
- 20 May, 2020 22 commits
-
-
Manos Koukoutos authored
Changes: - Implement the 'let' opcode, as per https://github.com/WebAssembly/function-references/blob/master/proposals/function-references/Overview.md#local-bindings - Use a WasmDecoder in place of a plain decoder in OpcodeLength and AnalyzeLoopAssignment. - Change ControlBase to accept an additional 'locals_count' parameter. - Implement required test infrastructure and write some simple tests. Bug: v8:7748 Change-Id: I39d60d1f0c26016c8f89c009dc5f4119b0c73c87 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2204107 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#67937}
-
Manos Koukoutos authored
We would like DecodeLocals to allow inserting new locals in any position. This is useful for the upcoming 'let' instruction. Bug: v8:7748 Change-Id: Ic7f2a7fba0f69ee76b0ace46bb0cecee9d047306 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208859 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#67936}
-
Milad Farazmand authored
load_extend is now implanted on BE machines by loading bytes and using replace_lane to add it to the desired lane. Interpret is also fixed to write lanes in reverse. Change-Id: I984ae6b4bd41544fbf65c702a4b5b50ba03cb261 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210147 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: Iac2146621689e0939cc7be656d5098ff1c8159a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207652 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port 6b228044 Original Commit Message: This is a reland of dd19a400 Original change's description: > [wasm-simd][liftoff][x64][ia32] Implement load extend > > The operations are implemented: > > - i16x8.load8x8_s > - i16x8.load8x8_u > - i32x4.load16x4_s > - i32x4.load16x4_u > - i64x2.load32x2_s > - i64x2.load32x2_u > > on x64 and i32. The rest of the arch currently bail out, and will be > implemented in subsequent patches. > > The liftoff-compiler.cc code looks very similar to the one for LoadMem, > the only difference is special handling of kSplat v.s. kExtend. kExtend > always loads 8 bytes, so the bounds check and tracing is different. > Compared to LoadMem there is less need for pinning, since the result is > always going to be in a SIMD/FP register, which is different from the > index/addr register. > > The enum LoadTransformationKind was moved from > function-body-decoder-impl.h to function-body-decoder.h so that no > unncessary header file inclusions were needed to liftoff, and also it's > a better place for it to live. > > Bug: v8:9909 > Change-Id: I926bcc01c0c3c860223e8c08f91bc4ab3b75c399 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203730 > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67914} R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2745871868afc1e6120197ad3ad138c89d47521e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210764Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
-
Andreas Haas authored
There already became committers some month ago. R=adamk@chromium.org CC=ecmziegler@chromium.org, thibaudm@chromium.org Change-Id: Icac1c0265f4928dae3b89105cbc6f843f1d4e2af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210243Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#67932}
-
Andreas Haas authored
The implementation of the StreamingDecoder depends on async compilation. However, when the --single-threaded flag is set, async compilation is not available. Therefore V8 does not support streaming compilation at the moment if the --single-threaded flag is set. This CL is the first step to support streaming compilation in --single-threaded mode. This CL makes the StreamingDecoder an abstract class, and the current implementation a sub-class called AsyncStreamingDecoder. A follow-up CL will provided a second sub-class implementation for streaming compilation in --single-threaded mode. Bug: v8:10548 Change-Id: Ice5c01340d3df18f836a4a05d30571207ca8ccf6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208869 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67931}
-
Ng Zhi An authored
This is a reland of dd19a400 Original change's description: > [wasm-simd][liftoff][x64][ia32] Implement load extend > > The operations are implemented: > > - i16x8.load8x8_s > - i16x8.load8x8_u > - i32x4.load16x4_s > - i32x4.load16x4_u > - i64x2.load32x2_s > - i64x2.load32x2_u > > on x64 and i32. The rest of the arch currently bail out, and will be > implemented in subsequent patches. > > The liftoff-compiler.cc code looks very similar to the one for LoadMem, > the only difference is special handling of kSplat v.s. kExtend. kExtend > always loads 8 bytes, so the bounds check and tracing is different. > Compared to LoadMem there is less need for pinning, since the result is > always going to be in a SIMD/FP register, which is different from the > index/addr register. > > The enum LoadTransformationKind was moved from > function-body-decoder-impl.h to function-body-decoder.h so that no > unncessary header file inclusions were needed to liftoff, and also it's > a better place for it to live. > > Bug: v8:9909 > Change-Id: I926bcc01c0c3c860223e8c08f91bc4ab3b75c399 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203730 > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67914} Bug: v8:9909 Change-Id: Ic1d8dcc00d9c5af0d51100a947161eaa315b7659 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209268Reviewed-by:
-
Zhi An Ng authored
This reverts commit 611e4127. Reason for revert: https://crbug.com/1080367 Original change's description: > [Intl] Use new getDefaultHourCycle to replace old hack > > Use the ICU 67.1 new API DateTimePatternGenerator::getDefaultHourCycle > to replace a hack which get the pattern of "jjmm" to find out the > default hour cycle of a locale > Bump the required API version from 65 to 67 > > Bug: v8:10225 > Change-Id: I3378edacb6dfb8400357ac0bf3d5d50b9fe008bd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173875 > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67549} TBR=jkummerow@chromium.org,ftang@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:10225 Change-Id: I8bdfbdfc6c906814e5a7525cbde79c9cac854bd1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208811Reviewed-by:
-
Dominik Inführ authored
Instead of skipping LAB in PagedSpaceObjectIterator, make the space iterable by inserting a filler object into the LAB. Bug: v8:10315 Change-Id: I6d79c309b7b8180b2a173ebd5ebdf8a893e88c4d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210234Reviewed-by:
-
Gus Caplan authored
Math.random, while technically not having any effects which modify the surrounding JS state, does observably change between a no-side-effects evaluation and an actual evaluation, and can cause confusion. Change-Id: I4a41ac6fd3153a14245d5940fe52ada43ca05e0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207805Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Gus Caplan <me@gus.host> Cr-Commit-Position: refs/heads/master@{#67927}
-
Bill Budge authored
This is a reland of 4482f988 It's identical to the original CL so .. TBR=jgruber@chromium.org,tebbi@chromium.org Original change's description: > [torque] Port builtins-number-gen to Torque > > - Ports everything except Add. > > Builtins generated from this CL are slightly larger, e.g. Subtract > is 424 bytes on x64, as opposed to 400 bytes for the CSA version. > See https://crbug.com/v8/10521 > > Bug: v8:9891 > > Change-Id: Id85779eb26d8e51643d8a04f0a75090bc50ef5b2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191644 > Commit-Queue: Bill Budge <bbudge@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67910} Bug: v8:9891 Change-Id: I910c95db7bc044b2457364f4bfbbca46f0745bb9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209265 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
-
Richard Stotz authored
Bug: chromium:1084344 Change-Id: I027db944c179a686dd3352dfc4d59b3e92e4ac0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210239 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Jakob Gruber authored
This was introduced by https://crrev.com/c/2207137. Load offsets can be negative. Drive-by: Add a helper function to wrap the verbose static casts in bounds checks. Bug: chromium:1084872,chromium:1083450 Change-Id: I48934d04a8ab15a8fc347465064b190e32c00716 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209066 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#67924}
-
Bill Budge authored
- Undefined behavior resulted from constant 2147483648.0. Fixed by checking for an out of range integer before casting. Change-Id: I1c5093e546dde79babedb70fa4067756b853d206 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209266Reviewed-by:
-
Marja Hölttä authored
When we add waitAsync, void* backing_store_ is no longer sufficient, since we cannot guarantee that the BackingStore stays alive while we're (asynchronously) waiting. Bug: v8:10239 Change-Id: I0e4f6049eb0c01faf216a8c6865a41c6e42be3ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208854Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Thibaud Michaud authored
R=ahaas@chromium.org Bug: v8:10408 Change-Id: I002dbb69e847e871188259d66b2cfddaa6281d93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2206734 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Jakob Kummerow authored
Better return a validation error than assume that invalid modules can't reach invalid code paths. ClusterFuzz prefers errors over crashes. Bug: chromium:1084389 Change-Id: I67f0c2f48022cff8a7821901ddfdd42fa2c4a5c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209059 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Marja Hölttä authored
There's no need for it to be a JSArray. In the spec it's a List which roughly corresponds to FixedArray (but not JSArray). Gotchas: - There's no good point in time where we know the array length, since resolving might be interleaved with iteration. - Using ExtractFixedArray in places where we don't need to extract, since it takes care of things like allocating the resulting array in the right space etc. Drive-by fix: Previously we pre-allocated an array 1 elements too big, but never noticed it since the last element was the hole. Bug: v8:10506 Change-Id: I6a72fbf1fc0cc031f2c8bad9314c4ed21d544a0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202905Reviewed-by:
-
Richard Stotz authored
Opcodes for saturated conversions are 2 bytes long, hence EmitWithPrefix is necessary. Bug: chromium:1084344 Change-Id: I7b8821ba952abee6b113f705559f2f3572d0f7c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209058 Commit-Queue: Richard Stotz <rstz@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/620c56e..d8c6146 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Ibbeaf92d5dce50b6fa272b93ef60de5e4578af5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208935Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/base/trace_event/common: https://chromium.googlesource.com/chromium/src/base/trace_event/common/+log/dab187b..ef35868 Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1b904cc..1a96233 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/204a35a..c8f5482 Rolling v8/buildtools/linux64: git_revision:5ed3c9cc67b090d5e311e4bd2aba072173e82db9..git_revision:d0a6f072070988e7b038496c4e7d6c562b649732 Rolling v8/third_party/aemu-linux-x64: 5LzaFiFYMxwWXcgus5JjF74yr90M5oz9IMo29pTdoLgC..wCYE7BPak_YwqYwMPrwRw1mwSyAzsuX3tth_UvhHUEUC Rolling v8/third_party/android_platform: https://chromium.googlesource.com/chromium/src/third_party/android_platform/+log/716366f..c1f84dc Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/e9a8d37..503f81b Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/454f4ba..620c56e Rolling v8/third_party/fuchsia-sdk: https://chromium.googlesource.com/chromium/src/third_party/fuchsia-sdk/+log/277fe91..8ce2286 Rolling v8/third_party/zlib: https://chromium.googlesource.com/chromium/src/third_party/zlib/+log/90fc47e..94df8b7 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/de3e206..a0ee3ce Rolling v8/tools/swarming_client: https://chromium.googlesource.com/infra/luci/client-py/+log/160b445..7e86362 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I35d1312f952fcfea355eac2c42cf816e43fb6756 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208933Reviewed-by:
-
- 19 May, 2020 10 commits
-
-
Zhi An Ng authored
This reverts commit dd19a400. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/30448? Original change's description: > [wasm-simd][liftoff][x64][ia32] Implement load extend > > The operations are implemented: > > - i16x8.load8x8_s > - i16x8.load8x8_u > - i32x4.load16x4_s > - i32x4.load16x4_u > - i64x2.load32x2_s > - i64x2.load32x2_u > > on x64 and i32. The rest of the arch currently bail out, and will be > implemented in subsequent patches. > > The liftoff-compiler.cc code looks very similar to the one for LoadMem, > the only difference is special handling of kSplat v.s. kExtend. kExtend > always loads 8 bytes, so the bounds check and tracing is different. > Compared to LoadMem there is less need for pinning, since the result is > always going to be in a SIMD/FP register, which is different from the > index/addr register. > > The enum LoadTransformationKind was moved from > function-body-decoder-impl.h to function-body-decoder.h so that no > unncessary header file inclusions were needed to liftoff, and also it's > a better place for it to live. > > Bug: v8:9909 > Change-Id: I926bcc01c0c3c860223e8c08f91bc4ab3b75c399 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203730 > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67914} TBR=clemensb@chromium.org,zhin@chromium.org Change-Id: I2af6dfe6cd163d0dbc9f3a5ad4bfc5e622e76b63 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9909 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207665Reviewed-by:
-
Ng Zhi An authored
The operations are implemented: - i16x8.load8x8_s - i16x8.load8x8_u - i32x4.load16x4_s - i32x4.load16x4_u - i64x2.load32x2_s - i64x2.load32x2_u on x64 and i32. The rest of the arch currently bail out, and will be implemented in subsequent patches. The liftoff-compiler.cc code looks very similar to the one for LoadMem, the only difference is special handling of kSplat v.s. kExtend. kExtend always loads 8 bytes, so the bounds check and tracing is different. Compared to LoadMem there is less need for pinning, since the result is always going to be in a SIMD/FP register, which is different from the index/addr register. The enum LoadTransformationKind was moved from function-body-decoder-impl.h to function-body-decoder.h so that no unncessary header file inclusions were needed to liftoff, and also it's a better place for it to live. Bug: v8:9909 Change-Id: I926bcc01c0c3c860223e8c08f91bc4ab3b75c399 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203730 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Bug: v8:10501 Change-Id: Ib61f7957e1fd7cfa498bce28171b5f9e4b2f93c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191393 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Ng Zhi An authored
For load extends, we can use Ldr, which does not require us to manually calculate address - ld1r uses post-index, so we have to add the index ourselves. By checking the operation in the instruction-selector, we can set the addressing mode for load extends to be MRR, then use Ldr in the codegen. Bug: v8:9886 Change-Id: Ibcd22fa719cd6dafd2fd06e68066960db249b57a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207656Reviewed-by:
-
Bill Budge authored
This reverts commit 4482f988. Reason for revert: Causes Torque to break UBSAN https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/11235? [764/2199] ACTION //:run_torque(//build/toolchain/linux:clang_x64) FAILED: gen/torque-generated/bit-fields-tq.h gen/torque-generated/builtin-definitions-tq.h gen/torqu...(too long) python ../../tools/run.py ./torque -o gen/torque-generated -v8-root ../.. src/builtins/array-copywit...(too long) ../../src/torque/implementation-visitor.cc:778:36: runtime error: 2.14748e+09 is outside the range of representable values of type 'int' Original change's description: > [torque] Port builtins-number-gen to Torque > > - Ports everything except Add. > > Builtins generated from this CL are slightly larger, e.g. Subtract > is 424 bytes on x64, as opposed to 400 bytes for the CSA version. > See https://crbug.com/v8/10521 > > Bug: v8:9891 > > Change-Id: Id85779eb26d8e51643d8a04f0a75090bc50ef5b2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191644 > Commit-Queue: Bill Budge <bbudge@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67910} TBR=bbudge@chromium.org,jgruber@chromium.org,tebbi@chromium.org Change-Id: Ib124c893753973243563e32c25bc727a5df2ca53 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9891 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209264Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#67911}
-
Bill Budge authored
- Ports everything except Add. Builtins generated from this CL are slightly larger, e.g. Subtract is 424 bytes on x64, as opposed to 400 bytes for the CSA version. See https://crbug.com/v8/10521 Bug: v8:9891 Change-Id: Id85779eb26d8e51643d8a04f0a75090bc50ef5b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191644 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
-
Deepti Gandluri authored
Bug: v8:10506 Change-Id: I3fccaf640e23b5fcc7722164e2437b247684f824 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207919Reviewed-by:
-
Ng Zhi An authored
Convert wasm-value into internal::WasmValue, then to debug::WasmValue. This is then copied into a CDP protocol object via a new class, WasmValueMirror. Bug: v8:10347 Change-Id: I5778d2cc5701caf82e4a97ac329303e510695b74 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151130Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Kim-Anh Tran <kimanh@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67908}
-
Seth Brenith authored
This change updates some Torque-defined classes to include more precise field types where possible. It also updates those classes to use @generateCppClass. One field was removed because it's unused (PrototypeInfo::validity_cell), and two fields in StackFrameInfo actually became less precise because they're based on Script::name, which is an embedder-provided untyped Local<Value>. (Automatically generated accessors pointed out this bug easily.) This change also includes a couple of minor fixes in Torque. Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port 18ac08d0 Original Commit Message: This is a reland of 3cc981cb with a fix for data race detected by TSan. Original change's description: > [wasm][debug] Fix tier down during streaming compilation > > If the debugger is enabled while streaming compilation is happening, we > won't correctly tier down to Liftoff. This is because during streaming > compilation, we always compile for no debugging. Fixing that is a bit > tricky, since when the debugger is enabled, functions can either already > have finished compiling, or they are currently being compiled, or their > wire bytes are not received yet. > Instead of handling this correctly while streaming compilation is > running, we just recompile the whole module with Liftoff after streaming > compilation finished. > > For testing this, we use the existing tests for async compilation, and > enable --wasm-test-streaming, which compiles via the streaming decoder > even in the async compilation case. > > R=thibaudm@chromium.org > > Bug: v8:10531 > Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133 > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67882} R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I778a10eaba0016a9e897c8f71ac822c6b421350f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208901 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
-
