- 13 Oct, 2020 23 commits
-
-
Michael Achenbach authored
Bug: chromium:1137528 Change-Id: If49ed0b92c0f2b64cf7d6c30529a3647dda4e84d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467849Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#70486}
-
Clemens Backes authored
This reverts commit 3593ee83. Reason for revert: MSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/34798 Original change's description: > Reland "[csa] Fix semantics of PopAndReturn" > > This is a reland of 5e5eaf79 > > This CL fixes the "function returns address of local variable" issue > which GCC was complaining about by using inline assembly instead of > address of a local for getting stack pointer approximation. > > Original change's description: > > [csa] Fix semantics of PopAndReturn > > > > This CL prohibits using PopAndReturn from the builtins that > > have calling convention with arguments on the stack. > > > > This CL also updates the PopAndReturn tests so that even off-by-one > > errors in the number of poped arguments are caught which was not the > > case before. > > > > Motivation: > > > > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for > > dropping ALL JS arguments that are currently located on the stack. > > Disallowing PopAndReturn in builtins with stack arguments simplifies > > semantics of this instruction because in case of presence of declared > > stack parameters it's impossible to distinguish the following cases: > > 1) stack parameter is included in JS arguments (and therefore it will > > be dropped as a part of 'pop' number of arguments), > > 2) stack parameter is NOT included in JS arguments (and therefore it > > should be dropped in ADDITION to the 'pop' number of arguments). > > > > This issue wasn't noticed before because builtins with stack parameters > > relied on adapter frames machinery to ensure that the expected > > parameters are present on the stack, but on the same time the adapter > > frame tearing down code was effectively recovering the stack pointer > > potentially broken by the CSA builtin. > > > > Once we get rid of the arguments adapter frames keeping stack pointer > > in a valid state becomes crucial. > > > > Bug: v8:5269, v8:10201 > > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819 > > Commit-Queue: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70454} > > Tbr: tebbi@chromium.org > Bug: v8:5269 > Bug: v8:10201 > Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70483} TBR=tebbi@chromium.org,ishell@chromium.org,victorgomes@chromium.org Change-Id: Icbd71d744a519a58e49feb917109228631b9d9a3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5269 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467846Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#70485}
-
Milad Fa authored
Port 2c38a477 Original Commit Message: These instructions are not in the proposal, and will be unlikely to be requested (poor performance, insufficient use cases). As we get more instruction suggestions, these are sitting around on useful opcodes and we have to play musical chairs every time we prototype a new instruction. R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: Ia926a4b01ed6bc9b362adce68b9301e3fc86d942 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466625Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#70484}
-
Igor Sheludko authored
This is a reland of 5e5eaf79 This CL fixes the "function returns address of local variable" issue which GCC was complaining about by using inline assembly instead of address of a local for getting stack pointer approximation. Original change's description: > [csa] Fix semantics of PopAndReturn > > This CL prohibits using PopAndReturn from the builtins that > have calling convention with arguments on the stack. > > This CL also updates the PopAndReturn tests so that even off-by-one > errors in the number of poped arguments are caught which was not the > case before. > > Motivation: > > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for > dropping ALL JS arguments that are currently located on the stack. > Disallowing PopAndReturn in builtins with stack arguments simplifies > semantics of this instruction because in case of presence of declared > stack parameters it's impossible to distinguish the following cases: > 1) stack parameter is included in JS arguments (and therefore it will > be dropped as a part of 'pop' number of arguments), > 2) stack parameter is NOT included in JS arguments (and therefore it > should be dropped in ADDITION to the 'pop' number of arguments). > > This issue wasn't noticed before because builtins with stack parameters > relied on adapter frames machinery to ensure that the expected > parameters are present on the stack, but on the same time the adapter > frame tearing down code was effectively recovering the stack pointer > potentially broken by the CSA builtin. > > Once we get rid of the arguments adapter frames keeping stack pointer > in a valid state becomes crucial. > > Bug: v8:5269, v8:10201 > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819 > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70454} Tbr: tebbi@chromium.org Bug: v8:5269 Bug: v8:10201 Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#70483}
-
Daniel Bevenius authored
Currently there are a number of -Wsubobject-linkage warnings when compiling with gcc (formatted to fit 72 character lines): In file included from ... from ../../testing/gtest/include/gtest/gtest.h:10, from ../../testing/gtest-support.h:8, from ../../test/unittests/test-utils.h:20, from ../../test/unittests/compiler/backend/ instruction-selector-unittest.h:15, from ../../test/unittests/compiler/x64/ instruction-selector-x64-unittest.cc:9: ../../third_party/googletest/src/googletest/include/gtest/internal/ gtest-param-util.h: In instantiation of ‘class testing::internal::ParameterizedTestFactory<v8::internal::compiler:: InstructionSelectorChangeInt32ToInt64Test_ \ ChangeInt32ToInt64WithLoad_Test>’: ../../third_party/googletest/src/googletest/include/gtest/internal/ gtest-param-util.h:439:12: required from ‘testing::internal::TestFactoryBase* testing::internal::TestMetaFactory<TestSuite>::CreateTestFactory( testing::internal::TestMetaFactory<TestSuite>::ParamType) [with TestSuite = v8::internal::compiler:: InstructionSelectorChangeInt32ToInt64Test_ \ ChangeInt32ToInt64WithLoad_Test; testing::internal::TestMetaFactory<TestSuite>::ParamType = v8::internal::compiler::{anonymous}::LoadWithToInt64Extension]’ ../../third_party/googletest/src/googletest/include/gtest/internal/ gtest-param-util.h:438:20: required from here ../../third_party/googletest/src/googletest/include/gtest/internal/ gtest-param-util.h:394:7: warning: ‘testing::internal::ParameterizedTestFactory< v8::internal::compiler:: InstructionSelectorChangeInt32ToInt64Test_ \ ChangeInt32ToInt64WithLoad_Test >’ has a field ‘testing::internal::ParameterizedTestFactory< v8::internal::compiler:: InstructionSelectorChangeInt32ToInt64Test_ \ ChangeInt32ToInt64WithLoad_Test>::parameter_’ whose type uses the anonymous namespace [-Wsubobject-linkage] 394 | class ParameterizedTestFactory : public TestFactoryBase { | ^~~~~~~~~~~~~~~~~~~~~~~~ This commit moves the parameterized tests in question into the anonymous namespace to avoid the warnings. Change-Id: I9c4a8bd9f4e225ed14ab64f5433d5f5c102e01a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418723Reviewed-by:Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#70482}
-
Javad Amiri authored
Bug: v8:9533 Change-Id: I87d653147896530a4b5115b126d652f626dd4665 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463005Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#70481}
-
Clemens Backes authored
Whenever more then one value is pushed to the stack, we need to execute a check for growing the stack first (since https://crrev.com/c/2431525). This CL adds two missing checks. R=thibaudm@chromium.org Bug: chromium:1137582 Change-Id: I9755502dfdb77c03d1dde3e83fb7d33b9b99e499 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467796 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70480}
-
Maya Lekova authored
Bug: chromium:1052746 Change-Id: I6c1f888ed9a7f27d43872e24f8d8cf353a103f1a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461740 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70479}
-
Thibaud Michaud authored
The call to "GetSpilledRegistersForInspection" was invalidated by the call to "GetUnusedRegister" a few lines below. R=clemensb@chromium.org Bug: v8:10957 Change-Id: I1e0110d9b28ca23a2a8b9ff4b4c39143bfbe5510 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466118 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Clemens Backes authored
The index to be traced can be a full (platform-dependent) pointer sized integer now. This CL prepares memory tracing for that. As a drive-by, the "address" field is renamed to "offset", or "effective_offset", depending on the situation. R=manoskouk@chromium.org Bug: v8:10949 Change-Id: I1fabfdb57835f041e1310a4eb4024d6254c08752 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465825Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#70477}
-
Andreas Haas authored
Rename the flag --liftoff-extern-ref to --experimental-liftoff-extern-ref to keep the fuzzer from using it. The implementation is not complete yet, and the next steps may take a bit. R=clemensb@chromium.org Bug: chromium:1137601 Change-Id: I74f1ed8faba44e42f63790d87f4a538dd59ac852 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465838Reviewed-by:
-
Georg Neis authored
A JSObject's own properties were always printed as if all were stored in the 'properties' backing store, even if some of them were stored in the descriptor array and/or in-object. This CL tries to make the output a bit clearer. Change-Id: I03d05bdd530cc4c534c945aa08bad20edc3bbcd7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466119 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#70475}
-
Camillo Bruni authored
Use monotonic times for logging with --predictable. Bug: v8:10937, v8:10966, v8:10668 Change-Id: I3d4f0d48375f6f5d9fa375cf5393ff3afee7c0b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465829 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
-
Clemens Backes authored
We now remember whether the memory was 64 bit, in in this case force the index value to be an i64 instead of an i32. This is only the decoding part of this change. TurboFan and Liftoff will have to be fixed separately to handle the i64 values correctly. R=manoskouk@chromium.org Bug: v8:10949 Change-Id: Ia504e7eb5a2a55caf8dfdbd0833481ef590c55bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461239 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Andreas Haas authored
The generic wrapper will be the baseline variant of the JavaScript-to- WebAssembly wrapper. Enabling it in the nooptimization variant gives it test coverage. R=clemensb@chromium.org Bug: v8:10701 Change-Id: I37d1f767c61ff70e103d1742ef84f874c3804d7d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461240 Auto-Submit: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Code objects for builtins are immortal and immovable and can thus be dereferenced like read-only-objects. Bug: v8:10315 Change-Id: I60d961fee71056160ad2913bffe3ca50280cb9d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465835Reviewed-by:
-
Jakob Gruber authored
... to expose the memory region containing embedded builtins. Similar to `GetCodeRange`, which does the same for on-heap V8 Code objects. Bug: v8:11001 Change-Id: I1aa3ae650f161cabb410c61dbb6d364908370f8f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465461 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Zhao Jiazhong authored
Change-Id: I3f5dbb0fbae3862a6da4146b83e49986c8be3bdc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467015Reviewed-by:
-
Javad Amiri authored
This disables the following features for --enable-third-party-heap: - inline allocation: all allocation are directed to runtime for now until we have support for TPH inline allocation. - allocation site pretenuring: this feature relies on ephemeral memento objects placed after ordinary objects and is tightly coupled with V8's GC. - allocation folding in TurboFan: this feature assumes that objects of different size and type can be allocated on the same page using bump-pointer allocation. Bug: v8:9533 Change-Id: Idbdf1dac566f37db379e5d4b43e0741886f4e69b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463004 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Michael Achenbach authored
Bug: chromium:1137528 Change-Id: I1f00cdbe7af97e56f234cc140dc0039be346690a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465836Reviewed-by:
-
Peter Marshall authored
Always spend 1ms per iteration. Previously if the profilerthread took a long time to start up then we would skip through iterations and potentially not gather enough samples. This forces each iteration to take 1ms. Bug: v8:10996 Change-Id: I0dd7bb7e31636c9ebf5dd99110c8a976cbc8f045 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461727 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#70466}
-
mathetake authored
CreateFrameFromInternal always creates StackFrame from the frame at the index zero, which is fine for the usage in Trap::origin, but is a bug for Trap::trace Change-Id: Ia9471f600c5165ffc1c165b2f114b40acbe5b1e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465353 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/3110f72..18a5f87 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I0d602535bf0e696d5a96bacdf2a8a74774a7a0ed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467117Reviewed-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@{#70464}
-
- 12 Oct, 2020 17 commits
-
-
Ng Zhi An authored
These are still not in proposal, so they should be behind the post-mvp flag. Bug: v8:10972 Change-Id: I1b53307f334ddd8e21a095c13d7f7abb8ce05203 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465654 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#70463}
-
Ng Zhi An authored
On AVX, many instructions can have 3 operands, unlike SSE which only has 2. So on SSE we use DefineSameAsFirst on the dst. But on AVX, using that will cause some unnecessary moves. This patch changes a couple of F32x4 and S128 instructions to remove this restriction when AVX is supported. We can't use AvxHelper since it duplicates the dst for the call to the AVX instruction, which isn't what we want. The alternative is to redefine Mulps and other functions here, but there are other callsites that depend on this duplicated-dst behavior, so it's harder to change. We can migrate this as we move more logic over to non-DefineSameAsFirst for AVX. With the meshopt_decoder.js in the linked bug, it removes 8 SIMD movs (from a function that has 300+ lines of assembly.) Note that from agner's microarchitecture.pdf, page 127, "Elimination of move instructions", many times such moves can be eliminated by the processor. So this change won't speed up perf, but it helps a bit with binary size, and decoder pressure. Bug: v8:10116,v8:9561 Change-Id: I125bfd44e728ef08312620bc00f6433f376e69e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465653Reviewed-by:
-
Ng Zhi An authored
This implements i8x16.popcnt on arm64 and interpreter. Bug: v8:11002 Change-Id: Ia94a053d7e0a0c800057ac80865ba6f86ac7caf8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461058Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7e6351e..3110f72 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Iee2196a82440a19603db77170b8f224753ab5479 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466562Reviewed-by:
-
Ng Zhi An authored
Implement on interpreter and x64. Bug: v8:10997 Change-Id: I3537ce54e1b56cc3b04d91cb07c430c35b88c3aa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2459109 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70459}
-
Zhi An Ng authored
This reverts commit 5e5eaf79. Reason for revert: Failure on V8 Linux gcc https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8929? Original change's description: > [csa] Fix semantics of PopAndReturn > > This CL prohibits using PopAndReturn from the builtins that > have calling convention with arguments on the stack. > > This CL also updates the PopAndReturn tests so that even off-by-one > errors in the number of poped arguments are caught which was not the > case before. > > Motivation: > > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for > dropping ALL JS arguments that are currently located on the stack. > Disallowing PopAndReturn in builtins with stack arguments simplifies > semantics of this instruction because in case of presence of declared > stack parameters it's impossible to distinguish the following cases: > 1) stack parameter is included in JS arguments (and therefore it will > be dropped as a part of 'pop' number of arguments), > 2) stack parameter is NOT included in JS arguments (and therefore it > should be dropped in ADDITION to the 'pop' number of arguments). > > This issue wasn't noticed before because builtins with stack parameters > relied on adapter frames machinery to ensure that the expected > parameters are present on the stack, but on the same time the adapter > frame tearing down code was effectively recovering the stack pointer > potentially broken by the CSA builtin. > > Once we get rid of the arguments adapter frames keeping stack pointer > in a valid state becomes crucial. > > Bug: v8:5269, v8:10201 > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819 > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70454} TBR=tebbi@chromium.org,ishell@chromium.org Change-Id: I2673982a8f51cbecf421af11b0ce5ad5031fb406 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5269 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465656Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70458}
-
Ng Zhi An authored
This flag allows you to filter printing Wasm code to one particular function index. Bug: v8:10791 Change-Id: I400ccaadb8330e5e31e2faefdeddb169cdc85f71 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2459259 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Load lane loads a value from memory and replaces a single lane of a simd value. This implements the load (no stores yet) for x64 and interpreter. Bug: v8:10975 Change-Id: I95d1b5e781ee9adaec23dda749e514f2485eda10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444578 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Ng Zhi An authored
These instructions are not in the proposal, and will be unlikely to be requested (poor performance, insufficient use cases). As we get more instruction suggestions, these are sitting around on useful opcodes and we have to play musical chairs every time we prototype a new instruction. Bug: v8:10933 Change-Id: Ic7ce4e514c343d821f76b8c071e41f9bddfbd1ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2457669Reviewed-by:
-
Igor Sheludko authored
This CL prohibits using PopAndReturn from the builtins that have calling convention with arguments on the stack. This CL also updates the PopAndReturn tests so that even off-by-one errors in the number of poped arguments are caught which was not the case before. Motivation: PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for dropping ALL JS arguments that are currently located on the stack. Disallowing PopAndReturn in builtins with stack arguments simplifies semantics of this instruction because in case of presence of declared stack parameters it's impossible to distinguish the following cases: 1) stack parameter is included in JS arguments (and therefore it will be dropped as a part of 'pop' number of arguments), 2) stack parameter is NOT included in JS arguments (and therefore it should be dropped in ADDITION to the 'pop' number of arguments). This issue wasn't noticed before because builtins with stack parameters relied on adapter frames machinery to ensure that the expected parameters are present on the stack, but on the same time the adapter frame tearing down code was effectively recovering the stack pointer potentially broken by the CSA builtin. Once we get rid of the arguments adapter frames keeping stack pointer in a valid state becomes crucial. Bug: v8:5269, v8:10201 Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Use a doubly-nested switch on SimdType for conversions, this ensures that we handle all possible cases (and we actually missed one, converting i64x2 -> f32x4, which is added in this patch.) Bug: v8:10507 Change-Id: I493becb2616c51d02d5868f235653baba5a0b4af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464144 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Manual copy and paste of all code found in the namespace base. I didn't change any of the implementation code. Pull in a new file for optimized ARM implementation. Added a list of adaptions made to document what is different from chromium. Change-Id: I88b4af45437506cf57755e48fdfc88027a5aed33 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436610 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#70452}
-
Mythri A authored
For turboprop, it's a better tradeoff to reuse the code than specialising the code for a particular closure especially given we optimize quite early when compared to Turbofan. Bug: v8:9684 Change-Id: Icf5d8548bbdcac9e202dcf44c68e06cc4c732ba7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461242 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70451}
-
v8-ci-autoroll-builder authored
Rolling v8/base/trace_event/common: https://chromium.googlesource.com/chromium/src/base/trace_event/common/+log/23ef533..e0f2b84 Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1cb6993..7e6351e Rolling v8/third_party/aemu-linux-x64: FgthknmEoQugl3GqOyqz_RsAjIMmeLsa960mZcmhE9UC..PL87Lj_q7GOEzYJ2eJIJAzMtQbuLWVnmjDQPqfu2O64C Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/d82d30d..cd2eebd Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/1407cfd..b073999 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/f513a0b..7e5979b Rolling v8/tools/luci-go: git_revision:83c3df996b224edf5061840744395707a0e513e7..git_revision:576741d3eed0fa33971fb34cd823650e6f5b47fb Rolling v8/tools/luci-go: git_revision:83c3df996b224edf5061840744395707a0e513e7..git_revision:576741d3eed0fa33971fb34cd823650e6f5b47fb Rolling v8/tools/luci-go: git_revision:83c3df996b224edf5061840744395707a0e513e7..git_revision:576741d3eed0fa33971fb34cd823650e6f5b47fb Rolling v8/tools/swarming_client: https://chromium.googlesource.com/infra/luci/client-py/+log/44c13d7..d46ea76 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I5a5acd9aa6eeab96a1999d55654349cdfb664275 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465037Reviewed-by:
-
Pierre Langlois authored
This test allocates a large mapping and splits into kThunkBufferSize areas that it needs to be able to change permissions on. So kThunkBufferSize needs to be set to the largest page size possible, which is 64k at the moment. It doesn't matter if kThunkBufferSize is larger than the actual page size. Bug: v8:10808 Change-Id: I3a8947f04a7ec25be49a54015cd128e901065ea6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463404Reviewed-by:
-
Nico Hartmann authored
According to this change in chromium's DEPS https://chromium-review.googlesource.com/c/chromium/src/+/2446832 Bug: chromium:1137317 No-Try: true No-Presubmit: true Change-Id: I2b9e804f151834b58b77db1aca591e2eade91243 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465826 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
Zhao Jiazhong authored
Bug: v8:10201 Change-Id: I86cd6b73787cea307013dd311d048b20459ad573 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465052Reviewed-by:
-
