- 25 Feb, 2019 1 commit
-
-
Benedikt Meurer authored
We'll need one bit in the SharedFunctionInfo::flags to record whether it's safe to skip arguments adaptor frames (for v8:8895), so this just removes the SharedFunctionInfo::IsDerivedConstructorBit which is redundant, since the same information is already available in the SharedFunctionInfo::FunctionKindBits, and most places in the code use that already, with the exception of the JSConstructStubGeneric builtin. This changes the JSConstructStubGeneric builtin to just check the function kind instead of testing the explicit bit, which also makes this more consistent. It seems like there's not much overhead to that, doing an additional bitmasking plus two comparisons instead of one. This shouldn't really matter since invocation and execution of the constructors is going to dominate and optimized code inlines all of this anyways. If this turns out to affect performance, we can still look into encoding the FunctionKindBits more cleverly. Drive-by-fix: Move the FunctionKindBits first in the flags to avoid the shift when accessing the function kind. This seems logic, since for the actual boolean bit fields it doesn't matter where they are in the flags, whereas for the function kind this saves one shift. Bug: v8:8834, v8:8895 Change-Id: I184a8f5cc5c140bdc272cf9a5ad546093c457306 Reviewed-on: https://chromium-review.googlesource.com/c/1482915Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#59821}
-
- 21 Feb, 2019 1 commit
-
-
Benedikt Meurer authored
In the Crankshaft days we (mis)used the Representation to also express the various internal representations that the compiler understands. But with TurboFan we now have proper MachineRepresentation and MachineType, which do that independently. So there's no need to have this in the Representation class anymore, and instead the Representation class only needs to deal with the field representations. Bug: v8:8749, v8:8834, v8:8865 Change-Id: I34ea9558b5fdf20d6c7939b52762eaffd4316b06 Reviewed-on: https://chromium-review.googlesource.com/c/1479954 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59750}
-
- 15 Feb, 2019 3 commits
-
-
Igor Sheludko authored
... and verify that upper 32-bits of on-heap tagged values contain zero. This CL also removes scratch register argument from decompression snippets. Bug: v8:7703 Change-Id: Ia69d1c5de423c465735719ed07d92df03d9db97c Reviewed-on: https://chromium-review.googlesource.com/c/1460953 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59634}
-
Igor Sheludko authored
Bug: v8:8477, v8:8834 Change-Id: I5ff2df3988cde5f806cecc9e40259ba02f6265d2 Reviewed-on: https://chromium-review.googlesource.com/c/1473291Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#59619}
-
Jakob Kummerow authored
This takes heap-inl.h out of the "Giant Include Cluster". Naturally, that means adding a bunch of explicit includes in a bunch of places that relied on transitively including them before. As of this patch, no header file outside src/heap/ includes heap-inl.h. Bug: v8:8562,v8:8499 Change-Id: I65fa763f90e66afc30d105b9277792721f05a6d4 Reviewed-on: https://chromium-review.googlesource.com/c/1459659 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59617}
-
- 31 Jan, 2019 3 commits
-
-
Sigurd Schneider authored
1) Ensure 31bit Smis are enabled if pointer compression is. 2) Enable some code for 31bit Smis Bug: v8:8344 Change-Id: Ib1e68ebfcfd49e16d1548879b7670c88dc73449b Reviewed-on: https://chromium-review.googlesource.com/c/1445979 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59248}
-
Igor Sheludko authored
Bug: v8:8621, v8:8562 Change-Id: I79014f92ba95d21b31ff28cb615a01aa00d0d5d6 Reviewed-on: https://chromium-review.googlesource.com/c/1448271 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59245}
-
Igor Sheludko authored
movXXXp are replaced with respective movXXXq. Drive-by cleanup: unified the way we generate movq with other mov instructions. Bug: v8:8621, v8:8562 Change-Id: I5c65dccf4e460cad5c3cee3dfabfd6ce39abc244 Reviewed-on: https://chromium-review.googlesource.com/c/1446096 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59243}
-
- 30 Jan, 2019 1 commit
-
-
Igor Sheludko authored
addp, andp, cmpp, decp, incp, leap, negp, orp, subp, testp, xorp, shrp, sarp, shlp are replaced with respective quad-word instructions. Some wrongly-used xxxp instructions in regexp code are replaced with xxxl. Bug: v8:8621, v8:8562 Change-Id: If5fe3229a35805b8ef84d3e1ffa05cf9ed91ceef Reviewed-on: https://chromium-review.googlesource.com/c/1446451Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#59217}
-
- 17 Jan, 2019 1 commit
-
-
Clemens Hammacher authored
and TurboAssembler. Instead of listing all the different combinations of arguments (which is one more now, temporarily), just forward all arguments down via MacroAssembler and TurboAssembler to TurboAssemblerBase. Interestingly, this requires more specific types sometimes (int instead of size_t), since further down the forwarding chain, the compiler does not recognize any more that the value is a constant, and emits a warning about a possibly truncating implicit conversion. R=mstarzinger@chromium.org Bug: v8:8689, v8:8562 Change-Id: Ifd13d2210ee64251c0075c0d9b68cacd5107d9ab Reviewed-on: https://chromium-review.googlesource.com/c/1414913Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58869}
-
- 08 Jan, 2019 1 commit
-
-
Ross McIlroy authored
Remove the use of a jump table in the prologue of the deopt entries and instead pass the bailout id explicitly in a register when calling the deopt entry routine from optimized code. This unifies the logic with the way the Arm64 code works. It saves the following amount of memory in code stubs: - arm: 384KB - ia32: 480KB - x64: 240KB This could be offset by a slight increase in the size of optimized code for loading the immediate, however this impact should be minimal and will scale with the maximum number of bailout ids (e.g., the size of code will increase by one instruction per bailout id on Arm, therefore ~98,000 bailouts will be needed before the overhead is greater than the current fixed table size). Change-Id: I838604b48fa04cbd45320c7b9dac0de08fd8eb25 Reviewed-on: https://chromium-review.googlesource.com/c/1398224 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#58636}
-
- 21 Dec, 2018 2 commits
-
-
Jakob Gruber authored
This CL does two things: 1. It introduces Call/JumpCodeObject as the bottleneck for all calls to non-heap-constant Code objects; and 2. it dispatches directly to the off-heap entry point for all embedded code. Codegen at runtime remains unchanged to preserve the shorter, branch-less calling sequence. Bug: v8:7777 Change-Id: I15fdcb51625209904c6a56737f085a23219319b9 Reviewed-on: https://chromium-review.googlesource.com/c/1382461 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#58440}
-
Igor Sheludko authored
Bug: v8:8477, v8:8562 Change-Id: I28a8244ef22035db85b520d86aa6d5578c7c7f5d Reviewed-on: https://chromium-review.googlesource.com/c/1384309 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58426}
-
- 20 Dec, 2018 1 commit
-
-
Jakob Gruber authored
This changes the CompileLazyDeoptimizedCode call to use the standard builtin calling sequence, which (for optimized code) creates an inlined off-heap trampoline instead of embedding a CODE_TARGET. Drive-by: Add missing conditional jump handling to masm::Jump. It was missing only for the case of inlined trampolines. Bug: v8:7777 Change-Id: Id79a10ba99fd97c1b3351774b9ecf5adf10ee6d4 Reviewed-on: https://chromium-review.googlesource.com/c/1382460 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#58389}
-
- 19 Dec, 2018 1 commit
-
-
Igor Sheludko authored
and fix platform builtins. This CL also introduces MacroAssembler::xxx_tagged() operations which operate on potentially compressed tagged values without doing decompression. This CL also drive-by fixes compilation failures when pointer compression is enabled. Bug: v8:7703 Change-Id: Id417f2a78907e8911aaa79ef404f5bcc87d9a3b8 Reviewed-on: https://chromium-review.googlesource.com/c/1382740Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#58352}
-
- 18 Dec, 2018 1 commit
-
-
Jakob Gruber authored
This is to fix the pointer compression bot, which tests only x64. Other 64-bit architectures will need similar work in the future. On x64 with pointer compression, smi-untagging can be folded into the Operand calculation since the left-shift for multiplying by kSystemPointerSize is greater than the right-shift for untagging. Bug: v8:7777 Change-Id: I5c46e9d3f51580341cfc3c12a7e32d17cf0b63ee Reviewed-on: https://chromium-review.googlesource.com/c/1381452 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#58328}
-
- 17 Dec, 2018 2 commits
-
-
Jakob Gruber authored
This changes Torque's builtin pointers to use a Smi representation underneath instead of storing the Code target object. Callsites look up the target entry point through IsolateData::builtin_entry_table. The notable effect of this CL is that builtin pointer calls no longer call any on-heap Code. Bug: v8:7777 Change-Id: Ibf6c749dd46cae7aba51494b09921229dd436f63 Reviewed-on: https://chromium-review.googlesource.com/c/1379880 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58286}
-
Jakob Gruber authored
Currently, Torque's builtin pointers store a Code target underneath and callsites generate a kArchCallCodeObject opcode. When embedded builtins are enabled, the call thus first calls the on-heap trampoline, which finally jumps to the target off-heap builtin code. This will no longer be possible in jitless mode, since on-heap code must not be executable. As a step towards changing the way builtin pointers are called (function pointers will hold the builtin index as a Smi, and callsites look up the off-heap target address and jump there), this CL adds a dedicated opcode for builtin pointer calls to the compiler pipeline. The calling mechanism itself is unchanged, changes there will happen in a follow-up. Drive-by: rename 'FunctionPointer' in torque/ to 'BuiltinPointer'. Bug: v8:7777 Change-Id: Ic999a1cd7c3172425dd4a1513ae2f50c774faddb Reviewed-on: https://chromium-review.googlesource.com/c/1378175Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58281}
-
- 11 Dec, 2018 1 commit
-
-
Jakob Gruber authored
This: - documents removal of Code's stub key field. - removes SerializedCodeData's CodeStubKeys field. - removes masm's custom self-reference marker mechanism. Bug: v8:7777 Change-Id: Ie5c51bc895e508acdeb3994cf5558a2cf4c21540 Reviewed-on: https://chromium-review.googlesource.com/c/1367744 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#58145}
-
- 07 Dec, 2018 4 commits
-
-
Jakob Gruber authored
This is a reland of f849396c Original change's description: > [nojit] Remove code stubs > > All stubs have been migrated to builtins. This CL removes most related > code. > > Bug: v8:7777, v8:5784 > Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad > Reviewed-on: https://chromium-review.googlesource.com/c/1365284 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58093} Tbr: mstarzinger@chromium.org,yangguo@chromium.org,jkummerow@chromium.org,bmeurer@chromium.org Bug: v8:7777, v8:5784 Change-Id: I005ee2a820d49a75a90481d262a310e4ccfd1391 Reviewed-on: https://chromium-review.googlesource.com/c/1367746Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58101}
-
Jakob Gruber authored
This reverts commit f849396c. Reason for revert: arm64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/24229 Original change's description: > [nojit] Remove code stubs > > All stubs have been migrated to builtins. This CL removes most related > code. > > Bug: v8:7777, v8:5784 > Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad > Reviewed-on: https://chromium-review.googlesource.com/c/1365284 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58093} TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org,bmeurer@chromium.org Change-Id: I52c3abd3f4e5872fe26ed7e527a58b118e02b387 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7777, v8:5784 Reviewed-on: https://chromium-review.googlesource.com/c/1367804Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58095}
-
Jakob Gruber authored
All stubs have been migrated to builtins. This CL removes most related code. Bug: v8:7777, v8:5784 Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad Reviewed-on: https://chromium-review.googlesource.com/c/1365284 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#58093}
-
Jakob Gruber authored
This migrates the JSEntryStub to three dedicated builtins: JSEntry JSConstructEntry JSRunMicrotasksEntry Drive-by: Tweaks to make the code isolate-independent (e.g. using the correct macro assembler method to load and store external references through the kRootRegister). Drive-by: The context slot on x64/ia32 must be set up after kRootRegister is initialized, so we first reserve the slot and later load its value. Drive-by: Update all remaining comments referencing JSEntryStub. Bug: v8:7777 Change-Id: Ie3ba17ffb3bde6f18ec1d26d778b258719b2d4ef Reviewed-on: https://chromium-review.googlesource.com/c/1365275Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58088}
-
- 29 Nov, 2018 2 commits
-
-
Peter Marshall authored
This is a reland of d5f4a33e Landing with test disabled for now. Original change's description: > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame > > Before fast C calls, store the current FP and PC on the isolate. When > iterating frames in SafeStackFrameIterator, check if these fields are > set and start iterating at the calling frame's FP instead of the current > FP, which will be in C++ code. We need to do this because c_entry_fp is > not set on the Isolate for Fast-C-Calls because we don't build an exit > frame. > > This change makes stack samples that occur within 'Fast-C-Calls' > iterable, meaning we can properly attribute ticks within the JS caller. > > Fast-C-Calls can't call back into JS code, so we can only ever have one > such call on the stack at a time, allowing us to store the FP on the > isolate rather than the stack. > > TBR=v8-mips-ports@googlegroups.com > > Bug: v8:8464, v8:7202 > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406 > Reviewed-on: https://chromium-review.googlesource.com/c/1340241 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com> > Reviewed-by: Alexei Filippov <alph@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57896} TBR=v8-mips-ports@googlegroups.com TBR=jgruber@chromium.org Bug: v8:8464, v8:7202 Change-Id: I260d5ab3bc12c9c4529fb52a297a1040dcaa8ebf Reviewed-on: https://chromium-review.googlesource.com/c/1354466 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#57935}
-
Michael Achenbach authored
This reverts commit ddaa1f0a. Reason for revert: Still flaky on windows. Maybe reland and keep skipped on windows? https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32%20-%20nosnap%20-%20shared/31002 https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/27826 Original change's description: > Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" > > This is a reland of d5f4a33e > > Original change's description: > > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame > > > > Before fast C calls, store the current FP and PC on the isolate. When > > iterating frames in SafeStackFrameIterator, check if these fields are > > set and start iterating at the calling frame's FP instead of the current > > FP, which will be in C++ code. We need to do this because c_entry_fp is > > not set on the Isolate for Fast-C-Calls because we don't build an exit > > frame. > > > > This change makes stack samples that occur within 'Fast-C-Calls' > > iterable, meaning we can properly attribute ticks within the JS caller. > > > > Fast-C-Calls can't call back into JS code, so we can only ever have one > > such call on the stack at a time, allowing us to store the FP on the > > isolate rather than the stack. > > > > TBR=v8-mips-ports@googlegroups.com > > > > Bug: v8:8464, v8:7202 > > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406 > > Reviewed-on: https://chromium-review.googlesource.com/c/1340241 > > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com> > > Reviewed-by: Alexei Filippov <alph@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#57896} > > TBR=v8-mips-ports@googlegroups.com > TBR=jgruber@chromium.org > > Bug: v8:8464, v8:7202 > Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274 > Reviewed-on: https://chromium-review.googlesource.com/c/1354042 > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57912} TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com Change-Id: If810648dbf60df2ff70455b6e8ef466136c90145 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8464, v8:7202 Reviewed-on: https://chromium-review.googlesource.com/c/1354461Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#57925}
-
- 28 Nov, 2018 3 commits
-
-
Peter Marshall authored
This is a reland of d5f4a33e Original change's description: > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame > > Before fast C calls, store the current FP and PC on the isolate. When > iterating frames in SafeStackFrameIterator, check if these fields are > set and start iterating at the calling frame's FP instead of the current > FP, which will be in C++ code. We need to do this because c_entry_fp is > not set on the Isolate for Fast-C-Calls because we don't build an exit > frame. > > This change makes stack samples that occur within 'Fast-C-Calls' > iterable, meaning we can properly attribute ticks within the JS caller. > > Fast-C-Calls can't call back into JS code, so we can only ever have one > such call on the stack at a time, allowing us to store the FP on the > isolate rather than the stack. > > TBR=v8-mips-ports@googlegroups.com > > Bug: v8:8464, v8:7202 > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406 > Reviewed-on: https://chromium-review.googlesource.com/c/1340241 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com> > Reviewed-by: Alexei Filippov <alph@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57896} TBR=v8-mips-ports@googlegroups.com TBR=jgruber@chromium.org Bug: v8:8464, v8:7202 Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274 Reviewed-on: https://chromium-review.googlesource.com/c/1354042Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#57912}
-
Maya Lekova authored
This reverts commit d5f4a33e. Reason for revert: Seems to cause a no snapshot build failure - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21967 Original change's description: > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame > > Before fast C calls, store the current FP and PC on the isolate. When > iterating frames in SafeStackFrameIterator, check if these fields are > set and start iterating at the calling frame's FP instead of the current > FP, which will be in C++ code. We need to do this because c_entry_fp is > not set on the Isolate for Fast-C-Calls because we don't build an exit > frame. > > This change makes stack samples that occur within 'Fast-C-Calls' > iterable, meaning we can properly attribute ticks within the JS caller. > > Fast-C-Calls can't call back into JS code, so we can only ever have one > such call on the stack at a time, allowing us to store the FP on the > isolate rather than the stack. > > TBR=v8-mips-ports@googlegroups.com > > Bug: v8:8464, v8:7202 > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406 > Reviewed-on: https://chromium-review.googlesource.com/c/1340241 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com> > Reviewed-by: Alexei Filippov <alph@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57896} TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com Change-Id: I85f846e57b6fa845e7770c616435cebffdb2a245 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8464, v8:7202 Reviewed-on: https://chromium-review.googlesource.com/c/1352302Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#57899}
-
Peter Marshall authored
Before fast C calls, store the current FP and PC on the isolate. When iterating frames in SafeStackFrameIterator, check if these fields are set and start iterating at the calling frame's FP instead of the current FP, which will be in C++ code. We need to do this because c_entry_fp is not set on the Isolate for Fast-C-Calls because we don't build an exit frame. This change makes stack samples that occur within 'Fast-C-Calls' iterable, meaning we can properly attribute ticks within the JS caller. Fast-C-Calls can't call back into JS code, so we can only ever have one such call on the stack at a time, allowing us to store the FP on the isolate rather than the stack. TBR=v8-mips-ports@googlegroups.com Bug: v8:8464, v8:7202 Change-Id: I7bf39eba779dad34754d5759d741c421b362a406 Reviewed-on: https://chromium-review.googlesource.com/c/1340241 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com> Reviewed-by: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#57896}
-
- 26 Nov, 2018 2 commits
-
-
Jakob Gruber authored
The ProfileEntryHookStub is no longer used and can be removed. Bug: v8:7777, v8:8503 Change-Id: I4ccd75d38cfee3e7963338d5d8213915db9be4a9 Reviewed-on: https://chromium-review.googlesource.com/c/1349191 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#57823}
-
Marja Hölttä authored
- Remove heap-inl.h includes from places where it looked unnecessary. (This is a non-scientific approach, because it's probably pulled in indirectly anyway.) - Annotate places which include heap-inl.h because they need heap/ internals. - ACCESSORS legitimately needs heap-inl.h because of Heap::FromWritableHeapObject. - Add includes to heap/heap-write-barrier(-inl).h - A bunch of IWYU fixes discovered when working on this CL (includes which were missing because heap-inl.h pulls them in indirectly). BUG=v8:7490,v8:8238,v8:8499 Change-Id: I00f9a74d430f13d7c080dca77a92b03bcca7ef96 Reviewed-on: https://chromium-review.googlesource.com/c/1349241Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#57814}
-
- 16 Nov, 2018 2 commits
-
-
Clemens Hammacher authored
The platform specific macro assembler headers can not be included directly. They require symbols declared in macro-assembler.h. We also cannot include macro-assembler.h from the platform specific headers, because that would form a cycle, and the include in macro-assembler.h would be skipped, which then also fails. This CL documents and enforces this unfortunate situation. This helps with further iwyu cleanups. Note that current code which includes the platform specific headers only works because we transitively included macro-assembler.h already before. R=mstarzinger@chromium.org Bug: v8:8238, v8:7490 Change-Id: I2dc65ad950400941406e1f2f8969d0d15f524bf8 Reviewed-on: https://chromium-review.googlesource.com/c/1340240 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57578}
-
Jakob Gruber authored
This pulls both classes into a dedicated file. InstructionStream may be removed in a follow-up. Tbr: mlippautz@chromium.org Bug: v8:6666 Change-Id: Ibd374eba25cebf7495390ec13f6b4aeac5e1dc01 Reviewed-on: https://chromium-review.googlesource.com/c/1337738Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57562}
-
- 13 Nov, 2018 1 commit
-
-
Tobias Tebbi authored
This CL is an experiment to get more performance data from the perf-bots and will likely lead to regressions. The try-bots (see patcheset 9) indicate some regressions, but it doesn't seem too bad. Change-Id: Ia173ab20ee2a4904663db0f4ca2ffb196b203c77 Reviewed-on: https://chromium-review.googlesource.com/c/1319763 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57483}
-
- 09 Nov, 2018 1 commit
-
-
Jakob Gruber authored
This is only used by ProfileEntryHookStub. For builtins, this also needs to go through an indirection. Bug: v8:6666 Change-Id: I088fa472e2d365ccfb2d027bfbdad182ffae487e Reviewed-on: https://chromium-review.googlesource.com/c/1326025Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57379}
-
- 08 Nov, 2018 1 commit
-
-
Igor Sheludko authored
Currently, in debug mode the snippets check the result of decompression equals to the full value stored in the field. Bug: v8:7703 Change-Id: I0caa7fdaa7d346612084706ed96a4330fcb0c236 Reviewed-on: https://chromium-review.googlesource.com/c/1319575 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#57354}
-
- 07 Nov, 2018 1 commit
-
-
Igor Sheludko authored
because otherwise cleared weak references require special treatment during decompression. Bug: v8:7703 Change-Id: I38761d656c606e7ba7fc3075dffbd855a9f72302 Reviewed-on: https://chromium-review.googlesource.com/c/1322909 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#57315}
-
- 05 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
and split Smi out of objects.h into smi.h. Bug: v8:3770, v8:5402 Change-Id: I5ff7461495d29c785a76c79aca2616816a29ab1e Reviewed-on: https://chromium-review.googlesource.com/c/1313035Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#57252}
-
- 30 Oct, 2018 1 commit
-
-
Michael Starzinger authored
R=jgruber@chromium.org Change-Id: Ic9ef3cd231c2180563c3520ab58895f2ccce5408 Reviewed-on: https://chromium-review.googlesource.com/c/1307421Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57123}
-
- 26 Oct, 2018 1 commit
-
-
Jakob Kummerow authored
This CL applies the equivalent of the Object -> ObjectPtr transformation to MaybeObject and HeapObjectReference. We need no renaming in this case because we can just migrate them both in one go. Bug: v8:3770 Change-Id: Ie1259c3e8c556eff00f8bcf534d7270ca9fe00e1 Reviewed-on: https://chromium-review.googlesource.com/c/1298386 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57010}
-
- 25 Oct, 2018 1 commit
-
-
Michael Starzinger authored
This adds support for having reference type values (i.e. anyref) stored in an exception. It is the natural combination of the reference type proposal and the exception handling proposal. Note that this also introduces support for having write barriers in generated WasmCode, as this is the first time we are storing references within generated code. Such write barriers will be needed for other uses of reference types (e.g. mutable global) regardless. R=clemensh@chromium.org TEST=mjsunit/wasm/exceptions-anyref BUG=v8:8341 Change-Id: I1211d4a850954622cb873eede0b4024fecc3dd8b Reviewed-on: https://chromium-review.googlesource.com/c/1296484 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#56995}
-