- 22 Mar, 2021 1 commit
-
-
Deepti Gandluri authored
Removing prefetch operations as per the vote in the github issue: https://github.com/WebAssembly/simd/pull/352 Bug:v8:11168 Change-Id: Ia72684e68ce886f8f26a7d3b5bea601be416dfab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2771758Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#73578}
-
- 05 Feb, 2021 1 commit
-
-
Georgia Kouveli authored
This requires a small fix in {Push,Pop}CalleeSavedRegisters, where the return address was signed/authenticated at the wrong point, which meant the stack pointer used as modifier was different from the one the StackFrameIterator expected. Bug: v8:10026 Change-Id: Idebd2ee8f07312b5e99dd2ea5181fc7a7e4a87bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667861 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72542}
-
- 27 Jan, 2021 1 commit
-
-
Ng Zhi An authored
Prototype these 6 instructions on arm64: - f64x2.convert_low_i32x4_s - f64x2.convert_low_i32x4_u - i32x4.trunc_sat_f64x2_s_zero - i32x4.trunc_sat_f64x2_u_zero - f32x4.demote_f64x2_zero - f64x2.promote_low_f32x4 Drive-by fix: - f64x2.promote_low_f32x4 accesses out of bounds for the global, the result only has 2 doubles - fcvtn in simulator needs to clear top bits of the Q reg Bug: v8:11265 Change-Id: Icfb3338942f0d0374448fdcfef3847a6e3ce8ff6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644066Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#72373}
-
- 24 Nov, 2020 1 commit
-
-
Zhi An Ng authored
Prototype 2 prefetch instructions (temporal and non-temporal) on arm64 and interpreter. Add prfm to assembler, and use MiscField to encode the two versions. Small tweak to simulator to handle these new instructions (no-op). The implementation in the interpreter just pops the memory index and does nothing. Simple test cases added for these 2 new instructions, as well as a prefetch with OOB index, which should not trap. Bug: v8:11168 Change-Id: Ieced8081615d07f950d6d4c1128d1bc6a75839fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543167Reviewed-by:
Bill Budge <bbudge@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71353}
-
- 21 Oct, 2020 1 commit
-
-
Jakob Gruber authored
This is a reland of fbfa9bf4 The arm64 was missing proper codegen for CFI, thus sizes were off. Original change's description: > Reland "[deoptimizer] Change deopt entries into builtins" > > This is a reland of 7f58ced7 > > It fixes the different exit size emitted on x64/Atom CPUs due to > performance tuning in TurboAssembler::Call. Additionally, add > cctests to verify the fixed size exits. > > Original change's description: > > [deoptimizer] Change deopt entries into builtins > > > > While the overall goal of this commit is to change deoptimization > > entries into builtins, there are multiple related things happening: > > > > - Deoptimization entries, formerly stubs (i.e. Code objects generated > > at runtime, guaranteed to be immovable), have been converted into > > builtins. The major restriction is that we now need to preserve the > > kRootRegister, which was formerly used on most architectures to pass > > the deoptimization id. The solution differs based on platform. > > - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING. > > - Removed heap/ support for immovable Code generation. > > - Removed the DeserializerData class (no longer needed). > > - arm64: to preserve 4-byte deopt exits, introduced a new optimization > > in which the final jump to the deoptimization entry is generated > > once per Code object, and deopt exits can continue to emit a > > near-call. > > - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit > > sizes by 4/8, 5, and 5 bytes, respectively. > > > > On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes > > by using the same strategy as on arm64 (recalc deopt id from return > > address). Before: > > > > e300a002 movw r10, <id> > > e59fc024 ldr ip, [pc, <entry offset>] > > e12fff3c blx ip > > > > After: > > > > e59acb35 ldr ip, [r10, <entry offset>] > > e12fff3c blx ip > > > > On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases > > with CFI). Additionally, up to 4 builtin jumps are emitted per Code > > object (max 32 bytes added overhead per Code object). Before: > > > > 9401cdae bl <entry offset> > > > > After: > > > > # eager deoptimization entry jump. > > f95b1f50 ldr x16, [x26, <eager entry offset>] > > d61f0200 br x16 > > # lazy deoptimization entry jump. > > f95b2b50 ldr x16, [x26, <lazy entry offset>] > > d61f0200 br x16 > > # the deopt exit. > > 97fffffc bl <eager deoptimization entry jump offset> > > > > On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before: > > > > bb00000000 mov ebx,<id> > > e825f5372b call <entry> > > > > After: > > > > e8ea2256ba call <entry> > > > > On x64 the deopt exit size is reduced from 12 to 7 bytes. Before: > > > > 49c7c511000000 REX.W movq r13,<id> > > e8ea2f0700 call <entry> > > > > After: > > > > 41ff9560360000 call [r13+<entry offset>] > > > > Bug: v8:8661,v8:8768 > > Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834 > > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70597} > > Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org > Bug: v8:8661,v8:8768,chromium:1140165 > Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70655} Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org Bug: v8:8661 Bug: v8:8768 Bug: chromium:1140165 Change-Id: I471cc94fc085e527dc9bfb5a84b96bd907c2333f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488682Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70672}
-
- 20 Oct, 2020 3 commits
-
-
Maya Lekova authored
This reverts commit fbfa9bf4. Reason for revert: Seems to break arm64 sim CFI build (please see DeoptExitSizeIfFixed) - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/2808 Original change's description: > Reland "[deoptimizer] Change deopt entries into builtins" > > This is a reland of 7f58ced7 > > It fixes the different exit size emitted on x64/Atom CPUs due to > performance tuning in TurboAssembler::Call. Additionally, add > cctests to verify the fixed size exits. > > Original change's description: > > [deoptimizer] Change deopt entries into builtins > > > > While the overall goal of this commit is to change deoptimization > > entries into builtins, there are multiple related things happening: > > > > - Deoptimization entries, formerly stubs (i.e. Code objects generated > > at runtime, guaranteed to be immovable), have been converted into > > builtins. The major restriction is that we now need to preserve the > > kRootRegister, which was formerly used on most architectures to pass > > the deoptimization id. The solution differs based on platform. > > - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING. > > - Removed heap/ support for immovable Code generation. > > - Removed the DeserializerData class (no longer needed). > > - arm64: to preserve 4-byte deopt exits, introduced a new optimization > > in which the final jump to the deoptimization entry is generated > > once per Code object, and deopt exits can continue to emit a > > near-call. > > - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit > > sizes by 4/8, 5, and 5 bytes, respectively. > > > > On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes > > by using the same strategy as on arm64 (recalc deopt id from return > > address). Before: > > > > e300a002 movw r10, <id> > > e59fc024 ldr ip, [pc, <entry offset>] > > e12fff3c blx ip > > > > After: > > > > e59acb35 ldr ip, [r10, <entry offset>] > > e12fff3c blx ip > > > > On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases > > with CFI). Additionally, up to 4 builtin jumps are emitted per Code > > object (max 32 bytes added overhead per Code object). Before: > > > > 9401cdae bl <entry offset> > > > > After: > > > > # eager deoptimization entry jump. > > f95b1f50 ldr x16, [x26, <eager entry offset>] > > d61f0200 br x16 > > # lazy deoptimization entry jump. > > f95b2b50 ldr x16, [x26, <lazy entry offset>] > > d61f0200 br x16 > > # the deopt exit. > > 97fffffc bl <eager deoptimization entry jump offset> > > > > On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before: > > > > bb00000000 mov ebx,<id> > > e825f5372b call <entry> > > > > After: > > > > e8ea2256ba call <entry> > > > > On x64 the deopt exit size is reduced from 12 to 7 bytes. Before: > > > > 49c7c511000000 REX.W movq r13,<id> > > e8ea2f0700 call <entry> > > > > After: > > > > 41ff9560360000 call [r13+<entry offset>] > > > > Bug: v8:8661,v8:8768 > > Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834 > > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70597} > > Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org > Bug: v8:8661,v8:8768,chromium:1140165 > Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70655} TBR=ulan@chromium.org,rmcilroy@chromium.org,jgruber@chromium.org,tebbi@chromium.org Change-Id: I4739a3475bfd8ee0cfbe4b9a20382f91a6ef1bf0 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8661 Bug: v8:8768 Bug: chromium:1140165 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485223Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#70658}
-
Jakob Gruber authored
This is a reland of 7f58ced7 It fixes the different exit size emitted on x64/Atom CPUs due to performance tuning in TurboAssembler::Call. Additionally, add cctests to verify the fixed size exits. Original change's description: > [deoptimizer] Change deopt entries into builtins > > While the overall goal of this commit is to change deoptimization > entries into builtins, there are multiple related things happening: > > - Deoptimization entries, formerly stubs (i.e. Code objects generated > at runtime, guaranteed to be immovable), have been converted into > builtins. The major restriction is that we now need to preserve the > kRootRegister, which was formerly used on most architectures to pass > the deoptimization id. The solution differs based on platform. > - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING. > - Removed heap/ support for immovable Code generation. > - Removed the DeserializerData class (no longer needed). > - arm64: to preserve 4-byte deopt exits, introduced a new optimization > in which the final jump to the deoptimization entry is generated > once per Code object, and deopt exits can continue to emit a > near-call. > - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit > sizes by 4/8, 5, and 5 bytes, respectively. > > On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes > by using the same strategy as on arm64 (recalc deopt id from return > address). Before: > > e300a002 movw r10, <id> > e59fc024 ldr ip, [pc, <entry offset>] > e12fff3c blx ip > > After: > > e59acb35 ldr ip, [r10, <entry offset>] > e12fff3c blx ip > > On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases > with CFI). Additionally, up to 4 builtin jumps are emitted per Code > object (max 32 bytes added overhead per Code object). Before: > > 9401cdae bl <entry offset> > > After: > > # eager deoptimization entry jump. > f95b1f50 ldr x16, [x26, <eager entry offset>] > d61f0200 br x16 > # lazy deoptimization entry jump. > f95b2b50 ldr x16, [x26, <lazy entry offset>] > d61f0200 br x16 > # the deopt exit. > 97fffffc bl <eager deoptimization entry jump offset> > > On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before: > > bb00000000 mov ebx,<id> > e825f5372b call <entry> > > After: > > e8ea2256ba call <entry> > > On x64 the deopt exit size is reduced from 12 to 7 bytes. Before: > > 49c7c511000000 REX.W movq r13,<id> > e8ea2f0700 call <entry> > > After: > > 41ff9560360000 call [r13+<entry offset>] > > Bug: v8:8661,v8:8768 > Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70597} Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org Bug: v8:8661,v8:8768,chromium:1140165 Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70655}
-
Jakob Gruber authored
This reverts commit 7f58ced7. Reason for revert: Segfaults on Atom_x64 https://ci.chromium.org/p/v8-internal/builders/ci/v8_linux64_atom_perf/5686? Original change's description: > [deoptimizer] Change deopt entries into builtins > > While the overall goal of this commit is to change deoptimization > entries into builtins, there are multiple related things happening: > > - Deoptimization entries, formerly stubs (i.e. Code objects generated > at runtime, guaranteed to be immovable), have been converted into > builtins. The major restriction is that we now need to preserve the > kRootRegister, which was formerly used on most architectures to pass > the deoptimization id. The solution differs based on platform. > - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING. > - Removed heap/ support for immovable Code generation. > - Removed the DeserializerData class (no longer needed). > - arm64: to preserve 4-byte deopt exits, introduced a new optimization > in which the final jump to the deoptimization entry is generated > once per Code object, and deopt exits can continue to emit a > near-call. > - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit > sizes by 4/8, 5, and 5 bytes, respectively. > > On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes > by using the same strategy as on arm64 (recalc deopt id from return > address). Before: > > e300a002 movw r10, <id> > e59fc024 ldr ip, [pc, <entry offset>] > e12fff3c blx ip > > After: > > e59acb35 ldr ip, [r10, <entry offset>] > e12fff3c blx ip > > On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases > with CFI). Additionally, up to 4 builtin jumps are emitted per Code > object (max 32 bytes added overhead per Code object). Before: > > 9401cdae bl <entry offset> > > After: > > # eager deoptimization entry jump. > f95b1f50 ldr x16, [x26, <eager entry offset>] > d61f0200 br x16 > # lazy deoptimization entry jump. > f95b2b50 ldr x16, [x26, <lazy entry offset>] > d61f0200 br x16 > # the deopt exit. > 97fffffc bl <eager deoptimization entry jump offset> > > On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before: > > bb00000000 mov ebx,<id> > e825f5372b call <entry> > > After: > > e8ea2256ba call <entry> > > On x64 the deopt exit size is reduced from 12 to 7 bytes. Before: > > 49c7c511000000 REX.W movq r13,<id> > e8ea2f0700 call <entry> > > After: > > 41ff9560360000 call [r13+<entry offset>] > > Bug: v8:8661,v8:8768 > Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70597} TBR=ulan@chromium.org,rmcilroy@chromium.org,jgruber@chromium.org,tebbi@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:8661,v8:8768,chromium:1140165 Change-Id: I3df02ab42f6e02233d9f6fb80e8bb18f76870d91 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485504Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70649}
-
- 19 Oct, 2020 2 commits
-
-
Salome Thirot authored
This fixes a bug that made a test fail in mjsunit/wasm/return-call.js (the CFI bot does not run the tests with --variants=extra, hence why it didn't catch it). It also introduces --sim-abort-on-bad-auth, a debug flag for the arm64 simulator that stops a program as soon as an authentication error appears, to make debugging easier. Change-Id: Ibee731ab788aff45301d268ef05256b82f5e4613 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2473833 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70601}
-
Jakob Gruber authored
While the overall goal of this commit is to change deoptimization entries into builtins, there are multiple related things happening: - Deoptimization entries, formerly stubs (i.e. Code objects generated at runtime, guaranteed to be immovable), have been converted into builtins. The major restriction is that we now need to preserve the kRootRegister, which was formerly used on most architectures to pass the deoptimization id. The solution differs based on platform. - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING. - Removed heap/ support for immovable Code generation. - Removed the DeserializerData class (no longer needed). - arm64: to preserve 4-byte deopt exits, introduced a new optimization in which the final jump to the deoptimization entry is generated once per Code object, and deopt exits can continue to emit a near-call. - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit sizes by 4/8, 5, and 5 bytes, respectively. On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes by using the same strategy as on arm64 (recalc deopt id from return address). Before: e300a002 movw r10, <id> e59fc024 ldr ip, [pc, <entry offset>] e12fff3c blx ip After: e59acb35 ldr ip, [r10, <entry offset>] e12fff3c blx ip On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases with CFI). Additionally, up to 4 builtin jumps are emitted per Code object (max 32 bytes added overhead per Code object). Before: 9401cdae bl <entry offset> After: # eager deoptimization entry jump. f95b1f50 ldr x16, [x26, <eager entry offset>] d61f0200 br x16 # lazy deoptimization entry jump. f95b2b50 ldr x16, [x26, <lazy entry offset>] d61f0200 br x16 # the deopt exit. 97fffffc bl <eager deoptimization entry jump offset> On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before: bb00000000 mov ebx,<id> e825f5372b call <entry> After: e8ea2256ba call <entry> On x64 the deopt exit size is reduced from 12 to 7 bytes. Before: 49c7c511000000 REX.W movq r13,<id> e8ea2f0700 call <entry> After: 41ff9560360000 call [r13+<entry offset>] Bug: v8:8661,v8:8768 Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#70597}
-
- 30 Sep, 2020 1 commit
-
-
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}
-
- 09 Sep, 2020 1 commit
-
-
Jakob Kummerow authored
Apple's upcoming arm64 devices will prevent rwx access to memory, but in turn provide a new per-thread way to switch between write and execute permissions. This patch puts that system to use for the WebAssembly subsystem. The approach relies on CodeSpaceWriteScope objects for now. That isn't optimal for background threads (which could stay in "write" mode permanently instead of toggling), but its simplicity makes it a good first step. Background: https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon Bug: chromium:1117591 Change-Id: I3b60f0efd34c0fed924dfc71ee2c7805801c5d42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378307 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#69791}
-
- 05 Aug, 2020 1 commit
-
-
Jakob Gruber authored
With the new Turbofan variants (NCI and Turboprop), we need a way to distinguish between them both during and after compilation. We initially introduced CompilationTarget to track the variant during compilation, but decided to reuse the code kind as the canonical spot to store this information instead. Why? Because it is an established mechanism, already available in most of the necessary spots (inside the pipeline, on Code objects, in profiling traces). This CL removes CompilationTarget and adds a new NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine various things about a given code kind (e.g.: does this code kind deopt?). As a (very large) drive-by, refactor both Code::Kind and AbstractCode::Kind into a new CodeKind enum class. Bug: v8:8888 Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69244}
-
- 16 Jun, 2020 2 commits
-
-
Georgia Kouveli authored
Change-Id: I3d2da18477df775b6ecc8e358a02f4e838961831 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241522 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#68365}
-
Georgia Kouveli authored
The C++ code uses the A instruction key for return address signing, which is the default for Clang and GCC when the -mbranch-protection option is used (although this can be configured to use the B key). Using the B key for JS means that it's not possible to use an A key signing gadget to replace a return address signed with the B key and vice-versa. This should offer a degree of separation from the C++ side. Bug: v8:10026 Change-Id: Ia9dcc7ae7096c96b4a271efbe25fc02940f6fc8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2242953Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/master@{#68360}
-
- 09 Jun, 2020 1 commit
-
-
Ambroise Vincent authored
This includes the instruction opcode, its use in TF, its support in the simulator and the detection of the associated CPU feature. The instruction can be tested in the simulator with the new --sim-arm64-optional-features flag. Change-Id: I6047fa16696394fe0ced4535f7788d2c8716a18c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2222348Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68261}
-
- 17 Mar, 2020 1 commit
-
-
Georgia Kouveli authored
Generate a BTI instruction at each target of an indirect branch (BR/BLR). An indirect branch that doesn't jump to a BTI instruction will generate an exception on a BTI-enabled core. On cores that do not support the BTI extension, the BTI instruction is a NOP. Targets of indirect branch instructions include, among other things, function entrypoints, exception handlers and jump tables. Lazy deopt exits can potentially be reached through an indirect branch when an exception is thrown, so they also get an additional BTI instruction. Bug: v8:10026 Change-Id: I0ebf51071f1b604f60f524096e013dfd64fcd7ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967315 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66751}
-
- 24 Feb, 2020 1 commit
-
-
Richard Townsend authored
Changes the lambda capture for this test so that referenced variables are captured automatically. This means MSVC and Clang can compile the same test without compiler-specific #ifdef's. Bug: v8:10012 Change-Id: Ife4ee050e227478842c0f8def92adb0857082ccf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066984Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Richard Townsend <richard.townsend@arm.com> Cr-Commit-Position: refs/heads/master@{#66414}
-
- 19 Feb, 2020 1 commit
-
-
Georgia Kouveli authored
There are cases where we push FP and LR to the stack even though we have already created a frame and already stored them. Avoid doing this, by cleaning up the caller- and callee-saved register lists, and passing a LinkRegisterStatus argument to TruncateDoubleToI. Change-Id: I652e7ec346a99e94617f1ec6b13935f5d2f73e7f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060505 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66330}
-
- 13 Feb, 2020 1 commit
-
-
Georgia Kouveli authored
This is a reland of 137bfe47 Original change's description: > [arm64] Protect return addresses stored on stack > > This change uses the Arm v8.3 pointer authentication instructions in > order to protect return addresses stored on the stack. The generated > code signs the return address before storing on the stack and > authenticates it after loading it. This also changes the stack frame > iterator in order to authenticate stored return addresses and re-sign > them when needed, as well as the deoptimizer in order to sign saved > return addresses when creating new frames. This offers a level of > protection against ROP attacks. > > This functionality is enabled with the v8_control_flow_integrity flag > that this CL introduces. > > The code size effect of this change is small for Octane (up to 2% in > some cases but mostly much lower) and negligible for larger benchmarks, > however code size measurements are rather noisy. The performance impact > on current cores (where the instructions are NOPs) is single digit, > around 1-2% for ARES-6 and Octane, and tends to be smaller for big > cores than for little cores. > > Bug: v8:10026 > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782 > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66239} Bug: v8:10026 Change-Id: Id1adfa2e6c713f6977d69aa467986e48fe67b3c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051958Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/master@{#66254}
-
- 12 Feb, 2020 2 commits
-
-
Nico Hartmann authored
This reverts commit 137bfe47. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/13072 Original change's description: > [arm64] Protect return addresses stored on stack > > This change uses the Arm v8.3 pointer authentication instructions in > order to protect return addresses stored on the stack. The generated > code signs the return address before storing on the stack and > authenticates it after loading it. This also changes the stack frame > iterator in order to authenticate stored return addresses and re-sign > them when needed, as well as the deoptimizer in order to sign saved > return addresses when creating new frames. This offers a level of > protection against ROP attacks. > > This functionality is enabled with the v8_control_flow_integrity flag > that this CL introduces. > > The code size effect of this change is small for Octane (up to 2% in > some cases but mostly much lower) and negligible for larger benchmarks, > however code size measurements are rather noisy. The performance impact > on current cores (where the instructions are NOPs) is single digit, > around 1-2% for ARES-6 and Octane, and tends to be smaller for big > cores than for little cores. > > Bug: v8:10026 > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782 > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66239} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,neis@chromium.org,georgia.kouveli@arm.com Change-Id: I57d5928949b0d403774550b9bf7dc0b08ce4e703 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10026 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051952Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#66242}
-
Georgia Kouveli authored
This change uses the Arm v8.3 pointer authentication instructions in order to protect return addresses stored on the stack. The generated code signs the return address before storing on the stack and authenticates it after loading it. This also changes the stack frame iterator in order to authenticate stored return addresses and re-sign them when needed, as well as the deoptimizer in order to sign saved return addresses when creating new frames. This offers a level of protection against ROP attacks. This functionality is enabled with the v8_control_flow_integrity flag that this CL introduces. The code size effect of this change is small for Octane (up to 2% in some cases but mostly much lower) and negligible for larger benchmarks, however code size measurements are rather noisy. The performance impact on current cores (where the instructions are NOPs) is single digit, around 1-2% for ARES-6 and Octane, and tends to be smaller for big cores than for little cores. Bug: v8:10026 Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66239}
-
- 03 Feb, 2020 1 commit
-
-
Georgia Kouveli authored
Bug: v8:10026 Change-Id: I8ee836ee6298415a21cf487bc3d0e5f803fc6186 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965590 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66082}
-
- 14 Nov, 2019 2 commits
-
-
Clemens Backes authored
This removes {CPURegister::Is} and {CPURegister::is}, and just uses {CPURegister::operator==} instead. Drive-by: Use DCHECK_EQ and DCHECK_NE where possible. R=mstarzinger@chromium.org Bug: v8:9810 Change-Id: I03aad8b4223bd4ae37d468326a734f7a5c3c8061 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916202Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64956}
-
Clemens Backes authored
Just use the default {is_valid} method provided by RegisterBase. Drive-by: Also rename {CPURegList::IsValid} to {CPURegList::is_valid}. R=mstarzinger@chromium.org Bug: v8:9810 Change-Id: Ia3bc3c477e6329d63ffd00bca59762d9a6cf2fcc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916201 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64952}
-
- 04 Sep, 2019 1 commit
-
-
Tom Tan authored
Windows SDK defines `near` and `far` as macro in minwindef.h, so they cannot be used as variable name if Windows SDK header file is included for Windows build. Bug: chromium:893460 Change-Id: I5ed1076b965979b8e4e09958c1b6f0a698ec8d4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783839Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Tom Tan <Tom.Tan@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63559}
-
- 03 Sep, 2019 1 commit
-
-
Pierre Langlois authored
The `Instruction::IsValidImmPCOffset()` method was taking an `offset` argument in numbers of *instructions* while we were passing it numbers of *bytes*. See `Instruction::IsTargetInImmPCOffsetRange()` and `MacroAssembler::NeedExtraInstructionsOrRegisterBranch()`. As a result, we were 4 times too conservative when computing branch ranges going backwards, forcing us to generate the following sequence for TBZ more often than needed: ``` TBNZ <skip> B <target> skip: ``` This happened rarely for loops, but a lot when doing an early return from out-of-line calls to write barriers. Since out-of-line code is easily out of range of 8K, although the real range of TBZ is 32K. This fixes it by changing this method to take a byte offset instead of instructions, as this is more intuitive and in line with similar methods. For instance, `Instruction::ImmPcOffset()` returns an offset in bytes. The tests are adapted so that they would have caught such a bug: * TEST(far_branch_backward): This test used to only check the code worked if the branch was very far away, but it didn't test the range was correct. So this test was changed to check each branch type separately, and test in-range and out-of-range cases separately too. * TEST(far_branch_veneer_broken_link_chain): Because of the backwards range bug, this test wasn't actually testing what it should. The idea of the test is to make sure the MacroAssembler can still cope when the chain of links is broken after a veneer was emitted. But no veneers were ever emitted. Change-Id: Iddb5c683a71147455175f38fa7ae57da0a3e7337 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781058Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63518}
-
- 24 Jul, 2019 1 commit
-
-
Georgia Kouveli authored
Change-Id: I29c88d9e5de34e9a940b76ab76a40376d251c25f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373781 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#62901}
-
- 18 Jun, 2019 1 commit
-
-
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}
-
- 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}
-
- 04 Jun, 2019 1 commit
-
-
Joey Gouly authored
This fixes the assembler tests on Windows arm64, that were previously crashing. Bug: v8:9235 Change-Id: I616e6eb00bb71d70195787f80f8b54a9ae33abe6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634919 Commit-Queue: Martyn Capewell <martyn.capewell@arm.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#61981}
-
- 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}
-
- 27 May, 2019 1 commit
-
-
Jakob Kummerow authored
Drive-by: fix an #include that the gcov bot is missing Bug: v8:9183 Change-Id: I35d1b4e346a56799a5f49b7059a658d5ccfe75ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627548Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#61837}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 02 May, 2019 1 commit
-
-
Seth Brenith authored
On Windows, expanding the stack by more than 4 KB at a time can cause access violations. This change fixes a few known cases (and includes unit tests for those), and attempts to make stack expansion more consistent overall by using the AllocateStackSpace helper method everywhere we can, even when the offset is a small constant. On arm64, there was already a consistent method for stack pointer manipulation using the Claim and Drop methods, so Claim is updated to touch every page. Bug: v8:9017 Change-Id: I2dbbceeebbdefaf45803e9b621fe83f52234a395 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1570666 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#61186}
-
- 30 Apr, 2019 1 commit
-
-
Mike Stanton authored
Failure addressed by not exposing the new test to the jitless environment. (jgruber@ on TBR). New enum RelocInfo::COMPRESSED_EMBEDDED_OBJECT created to support compressed pointers in generated code. Enum name EMBEDDED_OBJECT changed to FULL_EMBEDDED_OBJECT. RelocInfo::[set_]target_object() abstract away the difference between FULL_EMBEDDED_OBJECT and COMPRESSED_EMBEDDED_OBJECT. Compressed embedded objects can only be created at this time on x64 with pointer compression turned on. Arm64 constant pools don't support compressed objects at this time. NOPRESUBMIT=true Bug: v8:7703 TBR: jgruber@chromium.org Change-Id: Ifff53b041bab09b4b8c3e16085e5df4aa2b99f4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588461Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#61104}
-
- 29 Apr, 2019 1 commit
-
-
Maciej Goszczycki authored
Switch all uses of NewCode and TryNewCode to CodeBuilder and remove these methods. NewCode and TryNewCode use a large number of default parameters, which makes it difficult to use and add any new ones. Large chunks of code were also duplicated across TryNewCode and NewCode. The previous CL (https://chromium-review.googlesource.com/c/v8/v8/+/1585736) added a new CodeBuilder class which allows much simpler building of Code objects. Bug: v8:9183 Change-Id: I9f6884f35a3284cbd40746376f0f27e36f9051b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585737 Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#61096}
-