Commit Graph

166 Commits

Author SHA1 Message Date
Manos Koukoutos
2d1c3ed604 [test] Remove some unused includes
Mostly test/cctest/.

Bug: v8:13006
Change-Id: I8853d38feb79bed6234a4354ab25a13255a1871b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755149
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81777}
2022-07-18 12:59:03 +00:00
Clemens Backes
dd74a0232c Replace STATIC_ASSERT with static_assert
Now that we require C++17 support, we can just use the standard
static_assert without message, instead of our STATIC_ASSERT macro.

R=leszeks@chromium.org

Bug: v8:12425
Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80524}
2022-05-13 13:46:27 +00:00
Peter Kasting
a7f4ca5fd0 Place bit_cast<>() in the v8::base:: namespace.
This prevents ambiguity errors in C++20 due to ADL when casting types in
std::, which gains std::bit_cast<>().

Bug: chromium:1284275
Change-Id: I25046d1952a9304852e481ad8b84049c6769c289
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625838
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80378}
2022-05-05 17:56:39 +00:00
Igor Sheludko
449ece383b Reland "[rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)"
This is a reland of commit 9d31f8663a
There were issues with --future flag implications on M1.

Original change's description:
> [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
>
> ... for V8 code space. The feature is currently disabled.
>
> In order to use fast W^X permission switching we must allocate
> executable pages with readable writable executable permissions (RWX).
> However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
> permission changing of RWX memory pages. This means that the code page
> headers must be allocated with RWX permissions too because otherwise
> it wouldn't be possible to allocate a large code page over the freed
> regular code page and vice versa.
>
> When enabled, the new machinery works as follows:
>
> 1) when memory region is reserved for allocating executable pages, the
>    whole region is committed with RWX permissions and then decommitted,
> 2) since reconfiguration of RWX page permissions is not allowed on
>    MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
>    to change them,
> 3) the request to set RWX permissions in the executable page region
>    just recommits the pages without changing permissions (see (1), they
>    were already allocated as RWX and then discarded),
> 4) in order to make executable pages inaccessible one must use
>    OS::DiscardSystemPages() instead of OS::DecommitPages() or
>    setting permissions to kNoAccess because the latter two are not
>    allowed by the MacOS (see (2)).
> 5) since code space page headers are allocated as RWX pages it's also
>    necessary to switch between W^X modes when updating the data in the
>    page headers (i.e. when marking, updating stats, wiring pages in
>    lists, etc.). The new CodePageHeaderModificationScope class is used
>    in the respective places. On unrelated configurations it's a no-op.
>
> The fast permission switching can't be used for V8 configuration with
> enabled pointer compression and disabled external code space because
> a) the pointer compression cage has to be reserved with MAP_JIT flag
>    which is too expensive,
> b) in case of shared pointer compression cage if the code range will
>    be deleted while the cage is still alive then attempt to configure
>    permissions of pages that were previously set to RWX will fail.
>
> This also CL extends the unmapper unit tests with permissions tracking
> for discarded pages.
>
> Bug: v8:12797
> Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80238}

Bug: v8:12797
Change-Id: I0fe86666f31bad37d7074e217555c95900d2afba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610433
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80259}
2022-04-28 14:08:11 +00:00
Adam Klein
10807c9f5e Revert "[rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)"
This reverts commit 9d31f8663a.

Reason for revert: crashes on Mac/arm64 bots:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20debug/5923/overview

Original change's description:
> [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
>
> ... for V8 code space. The feature is currently disabled.
>
> In order to use fast W^X permission switching we must allocate
> executable pages with readable writable executable permissions (RWX).
> However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
> permission changing of RWX memory pages. This means that the code page
> headers must be allocated with RWX permissions too because otherwise
> it wouldn't be possible to allocate a large code page over the freed
> regular code page and vice versa.
>
> When enabled, the new machinery works as follows:
>
> 1) when memory region is reserved for allocating executable pages, the
>    whole region is committed with RWX permissions and then decommitted,
> 2) since reconfiguration of RWX page permissions is not allowed on
>    MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
>    to change them,
> 3) the request to set RWX permissions in the executable page region
>    just recommits the pages without changing permissions (see (1), they
>    were already allocated as RWX and then discarded),
> 4) in order to make executable pages inaccessible one must use
>    OS::DiscardSystemPages() instead of OS::DecommitPages() or
>    setting permissions to kNoAccess because the latter two are not
>    allowed by the MacOS (see (2)).
> 5) since code space page headers are allocated as RWX pages it's also
>    necessary to switch between W^X modes when updating the data in the
>    page headers (i.e. when marking, updating stats, wiring pages in
>    lists, etc.). The new CodePageHeaderModificationScope class is used
>    in the respective places. On unrelated configurations it's a no-op.
>
> The fast permission switching can't be used for V8 configuration with
> enabled pointer compression and disabled external code space because
> a) the pointer compression cage has to be reserved with MAP_JIT flag
>    which is too expensive,
> b) in case of shared pointer compression cage if the code range will
>    be deleted while the cage is still alive then attempt to configure
>    permissions of pages that were previously set to RWX will fail.
>
> This also CL extends the unmapper unit tests with permissions tracking
> for discarded pages.
>
> Bug: v8:12797
> Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80238}

Bug: v8:12797
Change-Id: Ic07948e036db36326d464a2a901d052aa060a406
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3611665
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80239}
2022-04-27 23:29:11 +00:00
Igor Sheludko
9d31f8663a [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
... for V8 code space. The feature is currently disabled.

In order to use fast W^X permission switching we must allocate
executable pages with readable writable executable permissions (RWX).
However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
permission changing of RWX memory pages. This means that the code page
headers must be allocated with RWX permissions too because otherwise
it wouldn't be possible to allocate a large code page over the freed
regular code page and vice versa.

When enabled, the new machinery works as follows:

1) when memory region is reserved for allocating executable pages, the
   whole region is committed with RWX permissions and then decommitted,
2) since reconfiguration of RWX page permissions is not allowed on
   MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
   to change them,
3) the request to set RWX permissions in the executable page region
   just recommits the pages without changing permissions (see (1), they
   were already allocated as RWX and then discarded),
4) in order to make executable pages inaccessible one must use
   OS::DiscardSystemPages() instead of OS::DecommitPages() or
   setting permissions to kNoAccess because the latter two are not
   allowed by the MacOS (see (2)).
5) since code space page headers are allocated as RWX pages it's also
   necessary to switch between W^X modes when updating the data in the
   page headers (i.e. when marking, updating stats, wiring pages in
   lists, etc.). The new CodePageHeaderModificationScope class is used
   in the respective places. On unrelated configurations it's a no-op.

The fast permission switching can't be used for V8 configuration with
enabled pointer compression and disabled external code space because
a) the pointer compression cage has to be reserved with MAP_JIT flag
   which is too expensive,
b) in case of shared pointer compression cage if the code range will
   be deleted while the cage is still alive then attempt to configure
   permissions of pages that were previously set to RWX will fail.

This also CL extends the unmapper unit tests with permissions tracking
for discarded pages.

Bug: v8:12797
Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80238}
2022-04-27 22:05:21 +00:00
Igor Sheludko
fe392704aa Reland "[rwx][mac] Introduce RwxMemoryWriteScope"
This is a reland of commit 4d8e1846a7
One of the Mac arm64 bots failed to link an exported thread_local
static variable (crbug/1316800).

Original change's description:
> [rwx][mac] Introduce RwxMemoryWriteScope
>
> ... as a single bottleneck that encapsulates the semantics and
> implementation of fast per-thread W^X permission switching supported
> by Apple Silicon (arm64 M1).
> On other architectures this class is a no-op.
>
> Bug: v8:12797
> Change-Id: Ica842ff9f843e20b7f61fd7e80591e7a1fd29771
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3586986
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79994}

Bug: v8:12797
Change-Id: Ifbd15c233bb343f11daa89b1328b5bf65c4806f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3591332
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80011}
2022-04-19 08:48:47 +00:00
Deepti Gandluri
e73757beaa Revert "[rwx][mac] Introduce RwxMemoryWriteScope"
This reverts commit 4d8e1846a7.

Reason for revert: Blocks V8 roll, crbug.com/1316800

Original change's description:
> [rwx][mac] Introduce RwxMemoryWriteScope
>
> ... as a single bottleneck that encapsulates the semantics and
> implementation of fast per-thread W^X permission switching supported
> by Apple Silicon (arm64 M1).
> On other architectures this class is a no-op.
>
> Bug: v8:12797
> Change-Id: Ica842ff9f843e20b7f61fd7e80591e7a1fd29771
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3586986
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79994}

Bug: v8:12797
Change-Id: I81792567839e72b4147d009c0845b0c0de003eb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3590752
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80007}
2022-04-18 18:18:47 +00:00
Igor Sheludko
4d8e1846a7 [rwx][mac] Introduce RwxMemoryWriteScope
... as a single bottleneck that encapsulates the semantics and
implementation of fast per-thread W^X permission switching supported
by Apple Silicon (arm64 M1).
On other architectures this class is a no-op.

Bug: v8:12797
Change-Id: Ica842ff9f843e20b7f61fd7e80591e7a1fd29771
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3586986
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79994}
2022-04-14 15:20:40 +00:00
Georgia Kouveli
16b5fc3c57 [arm64] Remove template argument of PushCPURegList and friends
Callee saved registers do not include the LR anymore, so we can
now remove the last place where we pass a non-default template
argument to PushCPURegList/PopCPURegList (in the code generator).
This makes the template argument redundant, so we can remove the
template altogether.

Change-Id: I07f0c0a10840817df8a5afc1dc74330e290ce5bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571816
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/main@{#79842}
2022-04-07 09:12:45 +00:00
Leszek Swirski
8a0d1b6fe5 [codegen] Change RegList into a class
Modernise the RegList interface to be a proper class, rather than a
typedef to an integer, and add proper methods onto it rather than ad-hoc
bit manipulation.

In particular, this makes RegList typesafe, adding a DoubleRegList for
DoubleRegisters.

The Arm64 CPURegList isn't updated to use (or extend) the new RegList
interface, because of its weird type-erasing semantics (it can store
Registers and VRegisters). Maybe in the future we'll want to get rid of
CPURegList entirely and use RegList/DoubleRegList directly.

Change-Id: I3cb2a4d386cb92a4dcd2edbdd3fba9ef71f354d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516747
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79460}
2022-03-14 12:59:48 +00:00
Ng Zhi An
9fc11f9163 [cleanup] Rename RelocInfo::NONE to RelocInfo::NO_INFO to fix -Wshadow
NONE clashes with the PropertyAttributes::NONE, which is defined in
v8::internal namespace. PropertyAttributes have too many call sites
and depend on using the enums as masks, making it hard to convert
to an enum class. So we are changing the name instead.

Bug: v8:12244
Change-Id: Iec0be12c626549cca137aceeaee0e30fafab8b05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284003
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77956}
2021-11-17 19:11:40 +00:00
Nico Weber
574b105d63 Fix some -Wunreachable-code-aggressive warnings
Bug: chromium:1066980
Change-Id: I03a6b5253043bfb9825a1a64a1d9b060958e5a98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094866
Auto-Submit: Nico Weber <thakis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76293}
2021-08-16 06:45:22 +00:00
Deepti Gandluri
a33c82553d [wasm-simd] Remove PrefetchTemporal and PrefetchNonTemporal operations
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/+/2771758
Reviewed-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}
2021-03-22 17:47:49 +00:00
Georgia Kouveli
35b4f3a0e5 [arm64][cfi] Enable sim_abort_on_bad_auth by default.
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}
2021-02-05 10:23:40 +00:00
Ng Zhi An
dfe7c465d3 [wasm-simd][arm64] Prototype double precision conversion
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/+/2644066
Reviewed-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}
2021-01-27 17:03:09 +00:00
Zhi An Ng
7f770766d8 [wasm-simd][arm64] Prototype prefetch arm64
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/+/2543167
Reviewed-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}
2020-11-24 02:44:09 +00:00
Jakob Gruber
c7cb9beca1 Reland "Reland "[deoptimizer] Change deopt entries into builtins""
This is a reland of fbfa9bf4ec

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 7f58ced72e
>
> 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/+/2488682
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70672}
2020-10-21 06:01:38 +00:00
Maya Lekova
7c7aa4fa94 Revert "Reland "[deoptimizer] Change deopt entries into builtins""
This reverts commit fbfa9bf4ec.

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 7f58ced72e
>
> 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/+/2485223
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70658}
2020-10-20 14:14:12 +00:00
Jakob Gruber
fbfa9bf4ec Reland "[deoptimizer] Change deopt entries into builtins"
This is a reland of 7f58ced72e

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}
2020-10-20 12:30:23 +00:00
Jakob Gruber
8bc9a7941c Revert "[deoptimizer] Change deopt entries into builtins"
This reverts commit 7f58ced72e.

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/+/2485504
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70649}
2020-10-20 09:43:19 +00:00
Salome Thirot
39758cdf9f [arm64] Fixed authentication bug in liftoff PrepareTailCall
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}
2020-10-19 09:24:58 +00:00
Jakob Gruber
7f58ced72e [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}
2020-10-19 07:32:48 +00:00
Jakob Gruber
29bcdaad1d Rename legacy code kinds
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}
2020-09-30 15:39:23 +00:00
Jakob Kummerow
27e1ac1a79 [wasm][mac] Support w^x codespaces for Apple Silicon
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}
2020-09-09 20:57:52 +00:00
Jakob Gruber
c51041f454 [nci] Replace CompilationTarget with a new Code::Kind value
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}
2020-08-05 12:27:22 +00:00
Georgia Kouveli
5e29a9bcd7 [arm64] Only run FJCVTZS test when the instruction is available
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}
2020-06-16 14:38:42 +00:00
Georgia Kouveli
c65c1c10a5 [arm64] Use B instruction key for return address signing
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/+/2242953
Reviewed-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}
2020-06-16 11:02:59 +00:00
Ambroise Vincent
dfa0f31ac6 [arm64] Add FJCVTZS support
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/+/2222348
Reviewed-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}
2020-06-09 14:39:42 +00:00
Georgia Kouveli
ea82d0311b [arm64] Use BTI instructions for forward CFI
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}
2020-03-17 17:52:28 +00:00
Richard Townsend
e00fdf2dfe [arm64][msvc] fix cctest build for ARM64 MSVC
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/+/2066984
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Cr-Commit-Position: refs/heads/master@{#66414}
2020-02-24 21:25:32 +00:00
Georgia Kouveli
db59a4991d [arm64] Do not push FP and LR to the stack twice
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}
2020-02-19 10:37:14 +00:00
Georgia Kouveli
73f88b5f69 Reland "[arm64] Protect return addresses stored on stack"
This is a reland of 137bfe47c9

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/+/2051958
Reviewed-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}
2020-02-13 12:26:25 +00:00
Nico Hartmann
6a9a67d942 Revert "[arm64] Protect return addresses stored on stack"
This reverts commit 137bfe47c9.

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/+/2051952
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66242}
2020-02-12 15:07:54 +00:00
Georgia Kouveli
137bfe47c9 [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}
2020-02-12 13:59:44 +00:00
Georgia Kouveli
4eac274d32 [arm64] Add support for BTI instruction
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}
2020-02-03 15:21:59 +00:00
Clemens Backes
7762f53bb8 [arm64][cleanup] Remove CPURegister::Is and CPURegister::is
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/+/1916202
Reviewed-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}
2019-11-14 12:58:09 +00:00
Clemens Backes
8c2e512e07 [arm64][cleanup] Remove redundant {Register::IsValid}
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}
2019-11-14 12:12:52 +00:00
Tom Tan
61d6db0715 Renaming variables which conflict with macro definition in Windows SDK
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/+/1783839
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Tom Tan <Tom.Tan@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63559}
2019-09-04 20:37:48 +00:00
Pierre Langlois
ffffed9020 [arm64] Fix backwards branch ranges.
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/+/1781058
Reviewed-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}
2019-09-03 10:37:11 +00:00
Georgia Kouveli
7cb9984ef9 [arm64] Add support for pointer authentication instructions
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}
2019-07-24 17:00:26 +00:00
Sigurd Schneider
e93d244f23 Reland "[arm64] Refactor constant pool implementation"
This is a reland of ac79b539ec

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/+/1664054
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62237}
2019-06-18 11:34:26 +00:00
Sigurd Schneider
81fc0c462e Revert "[arm64] Refactor constant pool implementation"
This reverts commit ac79b539ec.

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/+/1662293
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62211}
2019-06-17 11:50:13 +00:00
Sigurd Schneider
ac79b539ec [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}
2019-06-17 10:53:39 +00:00
Sigurd Schneider
4c0bf17eb5 [arm64,test] Generate code object in assembler tests
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}
2019-06-12 11:44:28 +00:00
Joey Gouly
2e327e90d5 [arm64] Don't use x18 (platform register) in assembler tests
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}
2019-06-04 14:25:20 +00:00
Yang Guo
f455f86d89 Move architecture dependent files
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}
2019-05-28 14:02:15 +00:00
Jakob Kummerow
ffc7075260 [cleanup] Drop some dead (Macro)Assembler code
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/+/1627548
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61837}
2019-05-27 08:53:28 +00:00
Yang Guo
f9a88acbc9 Move remaining files in src/
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}
2019-05-24 18:24:36 +00:00
Yang Guo
a6eeea35cb Move code generation related files to src/codegen
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/+/1621931
Reviewed-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}
2019-05-21 10:33:39 +00:00