- 13 Jan, 2020 25 commits
-
-
Ng Zhi An authored
Bug: v8:10082 Change-Id: I68e540c5b68c62fd6d43075e5244a9794d6d3eda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980908 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#65739}
-
Ng Zhi An authored
Note the tricky part in instruction-selector-x64, where we flip the inputs given to the code generator. This is because the semantics we want is: v128.andnot a b = a & !b, but the x64 instruction performs andnps a b = !a & b. Therefore we flip the inputs, and combined with g.DefineSameAsFirst, the output register will be the same as b, and we can use andnps without any modifications in both SSE and AVX cases. Bug: v8:10082 Change-Id: Iff98dc1dd944fbc642875f6306c6633d5d646615 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980894Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#65738}
-
Mythri A authored
For measuring the time spent in each phase of TurboFan we use PipelineRunScope that adds a RuntimeCallStats scope with the correct counter. PipelineRunScope uses the runtimestats table set on the PipelineData to initialize the RuntimeCallStats scope. We correctly set the runtimestats on the pipelineData when starting ExecuteJobs but don't set it on PrepareJobs. This cl fixes it to also set runtimestats table on PrepareJobs. PrepareJobs always run on main thread, so it should be safe to use the runtimestats table on the isolate. Change-Id: Ied211158a10197aabb94373967146089a48c2db0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995386 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#65737}
-
Ulan Degenbaev authored
This adds inference for general JSObjects to NativeContextInferrer in the case when the object is going to be attributed to the shard context. Bug: chromium:973627 Change-Id: I393e8dd16a1f8b615fb2f8dceb52f543bae33554 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997133Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65736}
-
Santiago Aboy Solanes authored
TNodified: * LoadValueByKeyIndex * LoadPropertyFromGlobalDictionary * LoadDetailsByKeyIndex Bug: v8:10021 Change-Id: Ie992982d0b03962658f4ef30351f1f84e8ce027e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995394Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65735}
-
Pierre Langlois authored
Simulator-specific instructions are very useful, we can: - Place breakpoints that enable the simulator's interactive debugger, allowing us to see registers, the stack and print JS objects. - Enable and disable simulator tracing dynamically. - Call printf() directly, as the simulator cannot easily support its calling convention. However these tools are not available when generating builtins. The reason is that when cross-compiling, builtins are generated for real hardware but may still run inside the simulator on the host if we have a custom snapshot. Using the `v8_embed_script` GN option will do that for example but embedders may also do this with the V8 API. mksnapshot cannot tell the difference between generating code for a simulator build and a cross-build. If we change this, we can allow us to use simulator-specific features in builtins in simulator builds. So in this patch we: - Introduce a --target_is_simulator mksnapshot flag to drive the enable_simulator_code Assembler option. - Make sure the assembler respect the option instead of the USE_SIMULATOR macro. Change-Id: I7a7249f514427c1a2518a1af3679679596a72c7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991497Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#65734}
-
Santiago Aboy Solanes authored
TNodified: * StoreObjectField * StoreObjectFieldNoWriteBarrier Bug: v8:10021 Change-Id: I74b34af410c560a1b005c0b93c71468ef57087fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993296 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#65733}
-
Leszek Swirski authored
When looking up a variable in a deserialized WITH scope, we were unconditionally passing in the cache scope to the lookup, even if the with was inside the cache scope. This would lead to and outer scope of the with holding the generated dynamic variable. If the cache scope was the SCRIPT scope, the dynamic variable would be interpreted as a global object property. Now, we only store the WITH scope dynamic variables in the cache scope if it is an inner scope of the WITH scope, same as we do for 'normal' scope lookups. Fixed: chromium:1041210 Change-Id: I4e8eb25bbb8ea58311355d13a9c7c97bf2fa3ec7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997135Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65732}
-
Santiago Aboy Solanes authored
Bug: v8:10021 Change-Id: I2e27fbc52f9a42f1e52733e46a41227fbcaa8874 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995393Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65731}
-
Santiago Aboy Solanes authored
Bug: v8:10021 Change-Id: I78948e93ca61116a6a1a45ccbc1dfa7c27988c30 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995391Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65730}
-
Ross McIlroy authored
BUG=v8:10021 Change-Id: Ife3bdb70968c90813ea96e3eaacaa78712ba5540 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995396 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65729}
-
Toon Verwaest authored
Change-Id: I34aff1cef476a1237e59e8151b82bdb09819664f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997126 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65728}
-
Sigurd Schneider authored
The time was reported in milliseconds, but should be reported in seconds instead. TBR=ulan@chromium.org, szuend@chromium.org Change-Id: I171cdb0107cd522b0d62ac6ed4edfacf7599da0b Bug: chromium:1022031 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997137Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#65727}
-
Milad Farazmand authored
Due to the changes introduced int this CL: https://chromium-review.googlesource.com/c/v8/v8/+/1991498 wasm-scope-info-liftoff needs to be skipped until lifoff is enabled. Details can be found in the comment section of the above link. Change-Id: I1f61d1685a6ec2e81dab84b003f984a706d45737 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993906Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#65726}
-
Toon Verwaest authored
This makes the code a little more specific to what's happening: There is only 1 global scope, and if there is one, we know its declarations are info->scope()->declarations(). That means we don't need multiple GlobalDeclarationsBuilders, and we don't need to cache partially serialized versions of the declarations. One builder is enough, and we can simply walk those declarations if there are any. Additionally this CL drops unnecessary information passed into DeclareGlobals: - Global functions always have the name on the shared function info, so we can drop the name. - Due to lazy feedback vectors there's no point in trying to preinitialize global loads. Also this was only preinitializing global loads at the script level, not sub functions; without even checking whether the global load was used. It may actually have caused us to do more work and allocate more global load feedback slots than neccessary. Change-Id: Ibbdd029abe5a39ba27f7fc9be84670c5d444d98d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997123 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65725}
-
Dominik Inführ authored
This CL adds the ArrayBufferExtension class, which is used to track JSArrayBuffers in a linked list. The ArrayBufferExtension is going to replace the ArrayBufferTracker in the future but is currently behind the v8_enable_array_buffer_extension feature flag. When enabled, each JSArrayBuffer has a corresponding native-heap allocated ArrayBufferExtension object. All extensions are currently tracked in a single linked list. During marking the GC not only marks the JSArrayBuffer but also its extension object. At the end of mark-compact the GC iterates all extensions and removes unmarked ones. Change-Id: I88298be255944d5ae1327c91b0d7f0fdbcd486d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969791Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#65724}
-
Clemens Backes authored
This brings the test back in sync with the wasm-scope-info-liftoff test after the comments on https://crrev.com/c/1975754. R=jkummerow@chromium.org Bug: v8:10021 Change-Id: I8e3751fdb11fb32a0112c0706559a6d26e2e7594 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977860Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65723}
-
Tobias Tebbi authored
This is an improved version of https://chromium-review.googlesource.com/c/v8/v8/+/1981507 Bug: chromium:1031909 Change-Id: I552f49bf87340eee3c85fa02893b8e63a77a3608 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997129Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65722}
-
Simon Zünd authored
After the V8 internal stack frame cache was removed in https://crrev.com/c/1954392, the frames in stack traces will always have unique frame IDs. This renders the inspector side frame cache obsolete and this CL removes that cache. Change-Id: Icb72eec396e96b378ace09bc20fda03b09998c64 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997127 Auto-Submit: Simon Zünd <szuend@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#65721}
-
Jakob Kummerow authored
Bug: v8:10120 Change-Id: Ida81a4a4806bd2b4c19432412144b5e6f9c896e9 No-Try: true Tbr: clemensb@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997134Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65720}
-
legendecas authored
Fixed: v8:10083 Change-Id: I50e01022b1d1219ad8b31dd71f58f5bc9c9d10bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1987845 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65719}
-
Jakob Kummerow authored
This patch contains real changes affecting the following tests: - regress-1119: Bogus test, was failing justifiedly. Dropped. - regress-crbug-9161: Was accidentally disabled everywhere. Re-enabled for ASan (as the comment promised). - regress-crbug-160010: Throws "invalid string length" on all platforms. Was disabled everywhere. Dropped. - regress-crbug-514081: Test was previously changed to use 2MB instead of 2GB. Re-enabled variants. Additionally, it reorders a bunch of definitions: - Introduced separate sections for "mode == debug" and "no_i18n" to make the "ALWAYS" section cleaner. - Sorted various "slow tests", "open bugs", and "no_variants" definitions into groups. - Simplified long "arch == x or arch == y" sequences to "arch in (x, y)". Bug: v8:10021 Change-Id: Ibe404ae400011196473cf082a4706ddbef7c8349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995390Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65718}
-
arthursonzogni authored
It has been superseeded by SetModifyCodeGenerationFromStringsCallback. The new method has been introduced in M77 [1], in current form since M80 [2], default-used by Blink since M80 [3]. [1] https://crrev.com/b9342b7b5ff2e5588eceb503dd52bb1e3fbfb21c [2] https://crrev.com/6c0825aaa73ca3163f089ca161c1f6e15633f306 [3] https://crrev.com/bfd0621af3f09557e9713d5c76108c7dddaa49a6 Bug: v8:10096 Change-Id: If5475aaff9cfee29b42529cd158372b191d34f32 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1987252 Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#65717}
-
Zhao Jiazhong authored
port 57168634 https://crrev.com/c/1974961 Original Commit Message: Declare an inline method for the various backends to define based on alignment requirements. That way backends that might take a performance hit when data is not naturally aligned can specify the requirements. With this requirement defined, we can then specify that SIMD values require 16 bytes on the stack. This also opens up the possibility of storing 32-bit values in 32-bits, rather than the fixed kStackSlotSize. Change-Id: I928fb74ccdd31393dd76bda1dc76c5dc0e32975e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1994368 Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65716}
-
Jakob Kummerow authored
The regression test for crbug.com/976627 was: (1) silently failing on all platforms, (2) very brittle, baking in several internal limits, (3) highly specific for one particular place in the code, (4) when fixed, very slow: 6 seconds on x64.release. For all these reasons, it is herewith dropped. Bug: v8:10021 Change-Id: Ic144f6bfcca0c301f3aca7840edbdc43f34a77fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993975 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#65715}
-
- 12 Jan, 2020 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/32c9791..71813e2 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/fc132e6..7a8bf94 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Iee78bad75a9cda8044427f3907e119e773e8d258 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1994126Reviewed-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@{#65714}
-
- 11 Jan, 2020 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/1f6ff4c..32c9791 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/13928b7..fc132e6 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ibd3353dfa64f8167197f6aa864ed4b736b150f80 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1994124Reviewed-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@{#65713}
-
- 10 Jan, 2020 13 commits
-
-
Milad Farazmand authored
Change-Id: I60e839b0272a7dc13852549f543c9fa724f7fd36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1994821Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#65712}
-
Shu-yu Guo authored
Using the message listener is more in line with what Chromium does, and would allow d8 to report exceptions of JS tasks posted internally by V8 (e.g. FinalizationGroup cleanups). Bug: v8:8179 Change-Id: Ie058e1104818b77b2e8ca5e18173a7e68837c9e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986390 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65711}
-
Ng Zhi An authored
On most architectures, FP registers overlap with SIMD registers. A FP register holding a double can later be used to hold a 128-bit SIMD value. So, when pushing or popping used registers, we need to push the full width of the SIMD register. In ia32 and x64, we change the instruction from movsd to movdqu, and increment the offset by kSimd128Size. For arm64, we change the size of register when building the CPURegList. For arm, no change is needed, due to the way FP registers are paired up to form a single SIMD register (rather than overlap). Note for ports: PushRegisters and PopRegisters needs to be modified similarly for mips/mips64. ppc and s390 does not implement these methods, no change needed. Bug: v8:9909 Change-Id: If29f1b30d7eface305a0d07a4bc551c151a77a01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1994383 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65710}
-
Ross McIlroy authored
BUG=v8:10021 Change-Id: I4057928dcac9cbca58fe329dc7c65d6c11699de9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995389 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#65709}
-
Thibaud Michaud authored
This call to {ForwardStateTo} seems unnecessary, as suggested by the comment. R=sigurds@chromium.org Bug: v8:10021 Change-Id: I2ec3b54eda0cf5c53c2b5d3ad481a4581e024320 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993979Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#65708}
-
Nico Hartmann authored
Many binary operations defiend in CodeAssembler check for constants in the inputs and apply simplification if applicable. This is now performed by the MachineOperatorReducer in a uniform way. To avoid code duplication, the premature optimizations in CodeAssembler have been removed in this CL. Bug: v8:10021 Change-Id: I9b99f05e4f9ab31ff933f22d62674ee80efee8ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995277Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65707}
-
Milad Farazmand authored
Port 57168634 Original Commit Message: Declare an inline method for the various backends to define based on alignment requirements. That way backends that might take a performance hit when data is not naturally aligned can specify the requirements. With this requirement defined, we can then specify that SIMD values require 16 bytes on the stack. This also opens up the possibility of storing 32-bit values in 32-bits, rather than the fixed kStackSlotSize. R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ic61ba7508d37971a04fddad9e25025d038fdc3bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1994181Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#65706}
-
Clemens Backes authored
When comparing objects which get printed to very long strings (e.g. collections like vectors), it's much more readable if they get printed to individual lines. Differences are much easier to spot then. This CL refactors the CHECK/DCHECK macros to print the left hand side and right-hand side in individual lines if any of them is longer than 50 characters. To that end, the {PrintCheckOperand} method (only used from {MakeCheckOpString}) is changed to return the string directly instead of printing to an output stream. R=mlippautz@chromium.org Change-Id: I6e24a5cbfeb1af53fa0aca2828e23f642b15569c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991866Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65705}
-
Santiago Aboy Solanes authored
Related ones are TryGetOwnProperty and CallGetterIfAccessor. Bug: v8:10021 Change-Id: I1b65c4260ab48b4431fa2b84a8be5789f24fa800 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993960 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#65704}
-
Clemens Backes authored
This is a follow-up to https://crrev.com/c/1993969. --perf-basic-prof is only supported on linux platforms, thus the {PerfBasicLogger} class does not need to be compiled on other platforms. R=ahaas@chromium.org Bug: chromium:1035233 Change-Id: Ic84fb6922f6c4ea5147ba7b54fbf43e557d6d792 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993978Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65703}
-
Eric Leese authored
Change-Id: I7dd05e5b5feffceb1dd3b2a055c308266aea7c94 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995272Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Eric Leese <leese@chromium.org> Cr-Commit-Position: refs/heads/master@{#65702}
-
Seth Brenith authored
This change moves the definitions of the bitfield flags used by Symbol and Map to Torque. Symbol could directly follow the pattern established by SharedFunctionInfo, but Map required some other changes: - Until now, Torque bitfield definitions have required unsigned types. I thought that this would be the least-surprising behavior, since we never sign-extend when decoding bitfield values. However, I believe that the amount of churn involved in making ElementsKind be unsigned outweighs the benefit we were getting from this restriction (and similar difficulties are likely to arise in converting other bitfield structs to Torque), so this CL updates Torque to allow signed bitfield values. - If we try to make Map extend from all of the generated classes that define its flags, we end up with class sizing problems because some compilers only apply empty base class optimization to the first in a row of empty base classes. We could work around this issue by generating macros instead of classes, but I took this as an opportunity for a minor clean-up instead: rather than having bitfield definitions for several different bitfield structs all jumbled together in Map, they can be split up. I think this makes the code a little easier to follow, but if others disagree I'm happy to implement macro generation instead. Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65701}
-
Dominik Inführ authored
Change-Id: I826830e3eee1a597af183852ac8ab9f07706a8cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992429Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#65700}
-