- 16 Jul, 2019 1 commit
-
-
Shawn Presser authored
iOS uses 16kb memory pages. This change modifies OS::GetRandomMmapAddr() to return a 16kb-aligned address on apple ARM64. The mrs instruction is invalid on iOS. This change modifies CacheLineSizes::CacheLineSizes() so that mrs is not executed. Change-Id: I13fcc8498e715c03432c7a652ee723660f746069 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701127Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62730}
-
- 13 Jul, 2019 1 commit
-
-
Leszek Swirski authored
This reverts commit 13a04aba. Reason for revert: Breaks v8 roll (https://chromium-review.googlesource.com/c/chromium/src/+/1698024) Original change's description: > fix: move V8_EXPORT_PRIVATE marks to prevent unresolvable references > > This change fixes missing symbol errors in the Windows 10 on ARM build > of Node.js. > > When a whole class is marked for export, all of its members are marked > as well. This can be a problem when inline members call undefined yet > inline members of other classes: the exported function will contain a > reference to the undefined inline function that should be satisfied at > link time, but because the other function is inline no symbol will be > produced that will satisfy that reference. > > Clang gets around this by masking inlined class members from export > using /Fc:dllexportInlines-. This is why b0a2a567 worked. > > Node.js' Windows builds use MSVC and so do not have access to this > flag. This results in unresolved symbols at link time. > > Bug: v8:9465 > Change-Id: Ief9c7ab6ba35d22f995939eb62a64d6f1992ed85 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1696771 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62660} TBR=sigurds@chromium.org,jgruber@chromium.org,ishell@chromium.org,jkunkee@microsoft.com Change-Id: Ief2ccb35fc19b00975e78a63791a558525d49ee9 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9465 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700069Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#62694}
-
- 12 Jul, 2019 2 commits
-
-
Peter Marshall authored
Everyone was getting a copy of this through debug.h. Bug: v8:9396 Change-Id: I5189cb4bf27a3381768b0be479d7b3d60dec20bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695472 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62670}
-
Jon Kunkee authored
This change fixes missing symbol errors in the Windows 10 on ARM build of Node.js. When a whole class is marked for export, all of its members are marked as well. This can be a problem when inline members call undefined yet inline members of other classes: the exported function will contain a reference to the undefined inline function that should be satisfied at link time, but because the other function is inline no symbol will be produced that will satisfy that reference. Clang gets around this by masking inlined class members from export using /Fc:dllexportInlines-. This is why b0a2a567 worked. Node.js' Windows builds use MSVC and so do not have access to this flag. This results in unresolved symbols at link time. Bug: v8:9465 Change-Id: Ief9c7ab6ba35d22f995939eb62a64d6f1992ed85 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1696771Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62660}
-
- 05 Jul, 2019 1 commit
-
-
Sigurd Schneider authored
The functionality is identical and AddEmbeddedObject makes more effort to deduplicate handles. Change-Id: I3d0468da28596aad09ceceb320ca4038aed60bd4 Bug: v8:8054, v8:8977, v8:7703 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672925 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62538}
-
- 26 Jun, 2019 1 commit
-
-
Igor Sheludko authored
... in order to improve quality of C++ assembly. This CL also switches C++ code to use branchful decompression. Bug: v8:9353 Change-Id: Id6a5cc5db2ad729b4394cd541a7ec8035c0d4571 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677204 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#62372}
-
- 21 Jun, 2019 2 commits
-
-
Sigurd Schneider authored
v8memory.h does not have V8 specific definitions, and having it in base makes it clear that every component may include the file. It also ensures that including it does not create spurious dependencies on v8_base. Change-Id: I565f63b25f33a9ada19d7b2ac5990863ab17f4a7 Bug: v8:9183, v8:8855 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657923 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62309}
-
Sigurd Schneider authored
Adds basic support for CompressedHeapConstants to Arm64 by moving to a ldr_w instruction and passing COMPRESSED_EMBEDDED_OBJECT as the RelocInfo. However, we still haven't made the COMPRESSED_EMBEDDED_OBJECT be actually compressed in the code-stream (they still take up a full 64-bits). Support for this will be added next. Adding a test on macro assembler that checks that the RelocInfo::COMPRESSED_EMBEDDED_OBJECT is flowing through. Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng Bug: v8:8977, v8:7703, v8:9298 Change-Id: Ibc64cdfdd85d5cdfa060ed6227b10bb47eae3a8a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1635692Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62306}
-
- 18 Jun, 2019 2 commits
-
-
Sigurd Schneider authored
Change-Id: Iedb78a62886177f5c603b2f3ce9b586ac1320d31 Bug: chromium:968078 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664067Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62244}
-
Sigurd Schneider authored
This is a reland of ac79b539 This CL adds a missing BlockPoolsScope to guard a RequestHeapObject call. This fixes a latend bug that the original land flushed out. Original change's description: > [arm64] Refactor constant pool implementation > > This refactors the constant pool handling for arm64. The immediate goal > is to allow 32bit compressed pointers in the pool. The mediate goal is > to unify the implementation with the arm constant pool, which will be > done in a follow-up CL. > > Bug: v8:8054 > Change-Id: I74db4245e5e1025f2e4de4144090fa4ce25883ab > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645316 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62209} TBR=mstarzinger@chromium.org,jgruber@chromium.org,georgia.kouveli@arm.com Bug: v8:8054 Change-Id: I1e3ab13619a48caad33d77ed8bed86782f9d9674 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664054Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62237}
-
- 17 Jun, 2019 2 commits
-
-
Sigurd Schneider authored
This reverts commit ac79b539. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/18611 Original change's description: > [arm64] Refactor constant pool implementation > > This refactors the constant pool handling for arm64. The immediate goal > is to allow 32bit compressed pointers in the pool. The mediate goal is > to unify the implementation with the arm constant pool, which will be > done in a follow-up CL. > > Bug: v8:8054 > Change-Id: I74db4245e5e1025f2e4de4144090fa4ce25883ab > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645316 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62209} TBR=mstarzinger@chromium.org,sigurds@chromium.org,jgruber@chromium.org,georgia.kouveli@arm.com Change-Id: Iff03e81a2e70d125ef2c06b6ff3aff8d0e3688ef No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8054 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662293Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62211}
-
Sigurd Schneider authored
This refactors the constant pool handling for arm64. The immediate goal is to allow 32bit compressed pointers in the pool. The mediate goal is to unify the implementation with the arm constant pool, which will be done in a follow-up CL. Bug: v8:8054 Change-Id: I74db4245e5e1025f2e4de4144090fa4ce25883ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645316Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62209}
-
- 14 Jun, 2019 1 commit
-
-
Dan Elphick authored
This changes Generate_ContinueToBuiltinHelper to generate code to load the builtin address directly from the builtins table rather than going via the executable code in the trampoline's code object. The set up for Generate_ContinueToBuiltinHelper is changed so that the builtin index is stored on the stack in place of the builtin Code object which is no longer needed. Bug: v8:9338 Change-Id: I83f66af99fb27f131fc39ff426fdca4b1d674b70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648155 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#62170}
-
- 13 Jun, 2019 2 commits
-
-
Dan Elphick authored
Since TurboAssembler::CallBuiltinPointer actually takes the builtin_index as input, rename the function to CallBuiltinByIndex. Bug: v8:9183 Change-Id: I4958d96f18a48a2ec91525d80d597a35e45d5989 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657915 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#62151}
-
Sigurd Schneider authored
Previously, the handle's location was used as a proxy for the heap object, i.e, we put the handle into the constant pool, to avoid the need for GC visiting the constant pool entries during code generation. The handle locations are replaced by the corresponding heap object when the code is copied to the heap. This CL changes the handling in the assembler: Instead of putting in the handle location (which is a machine word) we put in a small index number into a table. This will be useful for putting 32bit constants into the constant pool. This new approach also has the advantage that ordering the constant pool entries by value produces a deterministic order after this change. Change-Id: Id47d56d487a0b64d1d1504a47937c8779ee02b13 Bug: v8:7703 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648094 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62144}
-
- 12 Jun, 2019 1 commit
-
-
Sigurd Schneider authored
This is pre-work for a refactoring that changes how heap objects are handled in the assembler: Currently, we put the handle location in the constant pool, and replace these with the actual heap object when we copy the code from the assembler's buffer to the heap. In the future, we will put a small index in the constant pool, which will ultimately enable 32bit constant pool slots for compressed heap objects. This small index will be fixed up when we copy the code to the heap. This CL makes the assembler tests copy the code to the heap, which ensures that the fix-up phase is actually run. Change-Id: I80cd69dc57414a3bd0a27f8d558616aadcae05a2 Bug: v8:7703 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1647166 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62112}
-
- 05 Jun, 2019 1 commit
-
-
Sigurd Schneider authored
Change-Id: I1660897803d826d6f2852186d5be7ce5650a32be Bug: v8:8054 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643431 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62002}
-
- 29 May, 2019 1 commit
-
-
Jakob Kummerow authored
So far, calls to Wasm C/C++ API functions reused the call descriptors of WasmImportWrappers, and the stack frame type of regular Wasm functions. This CL cleans that up by introducing separate implementations for both. No change in functionality or performance is expected. Change-Id: I79301fa81da52283cc776ddf19d4712372f3a58b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632235 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61914}
-
- 28 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I2f999ed3a8cc0931e5092f2ac6e709b8ff3f9e42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630678 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61896}
-