- 15 Oct, 2020 3 commits
-
-
Georg Neis authored
This reverts commit 44708a5b. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33692 Original change's description: > [compiler, heap] Create LocalHeap outside of ExecuteJob > > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and > pass its reference as argument to ExecuteJob. This allows us to create > LocalHeap differently for the main and background thread, e.g. by > passing an additional argument to the constructor in the future. > It will be required in the future anyways when the main thread will > have its own LocalHeap/LocalIsolate. > > Extending the scope of LocalHeap, also made > HandleBase::IsDereferenceAllowed more precise and uncovered two > potential issues: heap accesses in > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode > with --code-comments. > > LocalHeap can now be created in the parked state. Also fixed a data > race with LocalHeap's destructor publishing write barrier entries > without holding the lock. > > Bug: v8:10315 > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70521} TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,solanes@chromium.org,dinfuehr@chromium.org Change-Id: I9dd1f8ca6237d5716b6d8938cef0ee3f642f3166 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10315 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474118Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70522}
-
Dominik Inführ authored
Create LocalHeap directly in the Task or in GetOptimizedCodeNow and pass its reference as argument to ExecuteJob. This allows us to create LocalHeap differently for the main and background thread, e.g. by passing an additional argument to the constructor in the future. It will be required in the future anyways when the main thread will have its own LocalHeap/LocalIsolate. Extending the scope of LocalHeap, also made HandleBase::IsDereferenceAllowed more precise and uncovered two potential issues: heap accesses in OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode with --code-comments. LocalHeap can now be created in the parked state. Also fixed a data race with LocalHeap's destructor publishing write barrier entries without holding the lock. Bug: v8:10315 Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#70521}
-
Ng Zhi An authored
These instructions will be used for prototyping Wasm SIMD's store lane later on, separated the implementation for assembler and disassembler into this patch to make things smaller. Curiously, movhps and movlhps seems to have the same encoding, 0f 16, so I'm not sure not sure how to differentiate them in the disassembler besides using the mod field, since movlhps only takes xmm registers, whereas movhps always take 1 operand. Bug: v8:10975 Change-Id: I8be9a31b1c9a5515038f9c8c55ef30d1ba063ea7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471977Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70520}
-
- 14 Oct, 2020 5 commits
-
-
Ng Zhi An authored
Make everything consistent, pinsr family was converted in https://crrev.com/c/2443494. Bug: v8:10933 Change-Id: I9d09bd477520ce71fccdcf4336135b54c058185c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470203Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70517}
-
Ng Zhi An authored
We were already using it to define the SSE instructions. Bug: v8:10933 Change-Id: I8c70c027449ee8b0d00a06298087310ced11cafc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470200Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70516}
-
Victor Gomes authored
Change-Id: I2f262f4545de9e421310094d0dfab2f6147869b5 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466116Reviewed-by: Junliang Yan <junyan@redhat.com> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70502}
-
Victor Gomes authored
Change-Id: Ie8e2a87fa079b602f895c3c98053b7e7dfc61f45 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440098Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70497}
-
Jakob Gruber authored
This is a reland of 16cd5995 Changes since the original CL: generic lowering support for ForInPrepare and ForInNext. Original change's description: > [nci] Prepare JSForInPrepare and JSForInNext for feedback input > > These two operators are still missing feedback collection in generic > lowering (reminder: all operations that collect FB in the interpreter > must also collect FB in generic lowering). > > This CL prepares for that by adding the feedback vector as an input, > and additionally adds node wrappers to improve useability. > > The actual collection logic will be added in a following CL. > > Bug: v8:8888 > Change-Id: I04627eedb2dc237dc4e417091c44d2a95bd98f5f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454712 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70372} Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:8888 Change-Id: Idc294ffd2a24922edd08db6897d32d5724956995 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2459373 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70496}
-
- 13 Oct, 2020 4 commits
-
-
Igor Sheludko authored
This is a reland of 3593ee83 The MSAN doesn't seem to be considering initializing stores via inline assembly as such (in a new cctest helper GetStackPointer()), so this reland attempt fixes the issue and ensures that the MSAN bot is happy. 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 Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng Bug: v8:5269 Bug: v8:10201 Change-Id: Ib09af2d1260bb42ac26aabface14e6b83b3efec4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467847 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70492}
-
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}
-
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}
-
Zhao Jiazhong authored
Change-Id: I3f5dbb0fbae3862a6da4146b83e49986c8be3bdc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467015Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#70469}
-
- 12 Oct, 2020 3 commits
-
-
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}
-
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: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70454}
-
Zhao Jiazhong authored
Bug: v8:10201 Change-Id: I86cd6b73787cea307013dd311d048b20459ad573 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465052Reviewed-by: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70447}
-
- 09 Oct, 2020 2 commits
-
-
Samuel Groß authored
This change tags pointers in the external pointer table with a type dependent value in order to prevent type confusions between different external pointers. Bug: v8:10391 Change-Id: I5a83178e5ac46d49a99c91047816926120d801d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2443133Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Samuel Groß <saelo@google.com> Cr-Commit-Position: refs/heads/master@{#70430}
-
Ross McIlroy authored
BUG=v8:9684 Change-Id: I064b552b021597a80e57303cab3c2fbf552be6a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463228 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70427}
-
- 08 Oct, 2020 1 commit
-
-
Georg Neis authored
Bug: v8:7790 Change-Id: I1ffb2289f613a03d0246db2d66c3caaf0e4d6d2a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448796 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#70406}
-
- 07 Oct, 2020 3 commits
-
-
Ng Zhi An authored
The existing macro assembler define Pinsrb, which expects 3 arguments: - XMMRegister dst - Register/Operand src - uint8_t imm which overwrites dst with src at lane specified by imm. That means we cannot use the AVX version, which has 4 arguments, and does not overwrite dst. This refactoring defines the 4 argument AVX version instead, and if AVX is not supported, fall back to the SSE version, and ensure that the value is copied over into dst first. For convenience, we define an overload with 3 arguments that duplicates dst, this replicates the SSE behavior, so that not all callers have to be updated. Bug: v8:10975, v8:10933 Change-Id: I6f9b9d37fa08d3f5cff4f040ae7d5e1f0cf36455 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444096 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#70392}
-
Jakob Gruber authored
This removes a DCHECK that is no longer valid now that NCI jobs can also be spawned by OSR requests. Bug: v8:8888 Change-Id: I84eed41b510cc9c3ab1b35abfda0b6bec88752dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454714 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#70373}
-
Jakob Gruber authored
In addition to normal optimization requests, it also makes sense to consider OSR requests. In that case, the function is definitely hot, and since we've seen it OSR (i.e. we spend a long time inside a loop in the interpreted function), immediately jumping into NCI code in future contexts would be great. Future work: support OSR from NCI to TF. Bug: v8:8888 Change-Id: Iaa4c60bc0c2e1bf3dc067053bb7b50e9af51c0d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448462 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70364}
-
- 06 Oct, 2020 1 commit
-
-
Jakob Gruber authored
The NCI cache depends on the script cache (which is essentially a SharedFunctionInfo cache, and the SFIs contain bytecode) to deduplicate SFIs across native contexts. NCI caching does not work without script caching. Thus the lifetimes of both caches should match; in particular, disabling cache ageing for NCI is only effective if script cache ageing is also disabled. This CL adds an --isolate-script-cache-ageing flag. It's separate from the --turbo-nci-cache-ageing flag s.t. we can disable script cache ageing *without NCI* for benchmarking purposes. Future work: Good ageing heuristics for both script and nci caches. Bug: v8:8888 Change-Id: Ia5546feeced5821a538d97db1bb8f5bb92528114 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452471 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70339}
-
- 05 Oct, 2020 2 commits
-
-
Santiago Aboy Solanes authored
We can use tag dispatching to distinguish between the synchronized and non-synchronized accessors. Also eliminated the need of adding explicit "synchronized" in the name when using the macros. As a note, we currently have one case of using both relaxed and synchronized accessors (Map::instance_descriptors). Cleaned up: * BytecodeArray::source_position_table * Code::code_data_container * Code::source_position_table * FunctionTemplateInfo::call_code * Map::instance_descriptors * Map::layout_descriptor * SharedFunctionInfo::function_data Bug: v8:7790 Change-Id: I5a502f4b2df6addb6c45056e77061271012c7d90 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424130 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70306}
-
Jakob Gruber authored
Codegen timing and cache ageing are two important parameters for NCI performance. This adds runtime flags for them: --turbo-nci-cache-ageing (default: false) --turbo-nci-delayed-codegen (default: true) Note the behavioral change of disabling ageing by default for now. Bug: v8:8888 Change-Id: Id9611185566f5c4828ad48e58c42424833d3323b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438456 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70303}
-
- 02 Oct, 2020 1 commit
-
-
Ng Zhi An authored
It was slightly inconsistent, the sse versions took int8_t, the avx versions took uint8_t. Consolidate into uint8_t, that allows us to remove the DCHECK inside of the assembler, and also convert callers to use uint8_t. Bug: v8:10933 Change-Id: I125f0d54533b6fde1362e63e96f50fcf2467cac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2443494Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70274}
-
- 01 Oct, 2020 1 commit
-
-
Dan Elphick authored
CodeAssembler::Parameter now takes a Type template parameter and performs a checked cast to it. There is also UncheckedParameter which returns a TNode but doesn't check the cast. The original Parameter method is still there as UntypedParameter. Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the cast is performed inside Parameter. Since Parameter is not a macro, this means it cannot see the original expression or its file name and line number. So the error messages are vaguely useful, Parameter<T>() takes a SourceLocation parameter which with a default value of SourceLocation::Current(), which at least gives us the file name and line number for the error message. Bug: v8:6949, v8:10933 Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: Bill Budge <bbudge@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#70264}
-
- 30 Sep, 2020 4 commits
-
-
Milad Fa authored
This CL has started using new vector instructions introduced in Power 9, which includes: - Move To VSR Double Doubleword - Vector Extract Change-Id: Ieda677b33f4aae059afb3ab94d18f044001887a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438956Reviewed-by: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#70240}
-
Jakob Gruber authored
CodeKind::OPTIMIZED_CODE -> TURBOFAN Kinds are now more fine-grained and distinguish between TF, TP, NCI. CodeKind::STUB -> DEOPT_ENTRIES_OR_FOR_TESTING Code stubs (like builtins, but generated at runtime) were removed from the codebase years ago, this is the last remnant. This kind is used only for deopt entries (which should be converted into builtins) and for tests. Change-Id: I67beb15377cb60f395e9b051b25f3e5764982e93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440335 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#70234}
-
Victor Gomes authored
Change-Id: I33294dc5b93d5842a3a51779bfec30f20bf4f23f Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436345Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70220}
-
Jakob Gruber authored
Turboprop-generated Code objects will now have the dedicated TURBOPROP code kind instead of OPTIMIZED_FUNCTION. When possible, the code kind is used as the source of truth instead of FLAG_turboprop. This is the initial step towards implementing tier-up from Turboprop to Turbofan. Future work: Rename OPTIMIZED_FUNCTION to TURBOFAN, rename STUB to DEOPT_ENTRIES_OR_FOR_TESTING, implement TP tier-up. No-Try: true Bug: v8:9684 Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Change-Id: I3c9308718d7e9a2b7e6796e7ea94f17e5ff84c0a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424140 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70213}
-
- 29 Sep, 2020 3 commits
-
-
Samuel Groß authored
This change moves external pointers into a separate table and turns external pointers in heap objects into indices into that table. This CL implements one of two possible ownership models for the table entries. With this one, every heap object owns its table entries, and they are allocated when the owning object is allocated. As such, setting external pointer fields does not require allocation of table entries. On the other hand, table indices cannot be shared between multiple objects. This CL does not yet implement freeing of external pointer table entires. This will later happen by a table garbage collector. Bug: v8:10391 Change-Id: I4d37785295c25a7d1dcbc9871dd5887b9d788a4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235700Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Samuel Groß <saelo@google.com> Cr-Commit-Position: refs/heads/master@{#70204}
-
Santiago Aboy Solanes authored
We used to have a loop that it was used for JSReceivers. However, this was not used as a proper loop since at most it would have two loop iterations. Then, it could be changed to a Branch case. Since I was refactoring the method, I also de-duplicated code by using the common code from PlainPrimitiveNonNumberToNumber. In order to do so, said method was renamed to TryPlain... and was reworked as well. Bug: v8:6949, v8:10933 Change-Id: I860601a3b9e8bdeed052dcd237a767ac7ed80c92 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435110 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70202}
-
Sathya Gunasekaran authored
Instead of always inlining the polymorphic map checks, this CL introduces a builtin to perform these polymorphic map checks when the IC is monomorphic at compile time. This reduces the time we spend compiling and code bloat while trading it for performance. Bug: v8:10582, v8:9684 Change-Id: I7aea698988f8ead3cbf3f4a836218f53223f0f98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398525 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70200}
-
- 28 Sep, 2020 5 commits
-
-
Thibaud Michaud authored
Control-flow aware allocation has been enabled by default for a long time now. This removes the unused code paths related to splintering. R=neis@chromium.org Bug: v8:10933 Change-Id: I19d9eb448c3912b24a1ad16030e7dd556b13accc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434328Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70172}
-
Victor Gomes authored
- Improves return address prediction - Fix PopAndReturn CSA tests Change-Id: I5ed76e32bb997f47dcce725511a8653e34a4c398 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435369 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70169}
-
Maya Lekova authored
This CL also adds some unit tests, locally tested under x64. The double support is based on this original CL by Gus Caplan (snek@chromium.org): https://chromium-review.googlesource.com/c/v8/v8/+/2264612 Bug: chromium:1052746 Change-Id: Ibdf631689b01ab619a72005226bfc015b4737dde Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416028Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#70168}
-
Santiago Aboy Solanes authored
Previously ToNumber could be called with an empty context. In a previous CL (https://crrev.com/c/v8/v8/+/2078580) we added DCHECKS to make sure that some paths were not using the empty context. Now we are doing the next step of adding a primitive to separate the cases. Small update from delphick@ to get the builtin descriptor right. Bug: v8:6949, v8:10933 Change-Id: Ie40b169f680f60a08eb26fac1fcfcef7d6169e65 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428863 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70162}
-
Simon Zünd authored
The compilation cache doesn't know about REPL mode. This means that non-REPL mode compiled scripts are successfully found for their REPL mode equivalent and vice versa. This CL disables the compilation cache for REPL mode scripts. Performance is not really a concern as DevTools console inputs are usually very small. R=leszeks@chromium.org Bug: chromium:1108021 Change-Id: If396c7aa004188730762e4f6bd01dae2fc141181 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434333 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70160}
-
- 25 Sep, 2020 2 commits
-
-
Santiago Aboy Solanes authored
Bug: v8:9708, v8:6949 Change-Id: Ic219e0eb18648166a712493039f96e067ad47418 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2395555Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70141}
-
Tobias Tebbi authored
This is a reland of 64caf2b0 Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} Bug: v8:7793 TBR: hpayer@chromium.org jgruber@chromium.org Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70137}
-