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}
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}
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}
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}
CodeAssembler::Parameter now takes a Type template parameter and
performs a checked cast to it. There is also UncheckedParameter which
returns a TNode but doesn't check the cast. The original Parameter
method is still there as UntypedParameter.
Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the
cast is performed inside Parameter. Since Parameter is not a macro,
this means it cannot see the original expression or its file name and
line number. So the error messages are vaguely useful, Parameter<T>()
takes a SourceLocation parameter which with a default value of
SourceLocation::Current(), which at least gives us the file name and
line number for the error message.
Bug: v8:6949, v8:10933
Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70264}
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}
... to avoid the repeated pattern of calculating it.
Bug: v8:8888
Change-Id: I4af5264aae6cfb8b6232b5aaf9ceb2cb568c29d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362692
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69469}
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}
Adds support for populating reference maps to the fast
register allocator. In order to calculate whether a stack slot
is live at a given instruction, we use the dominator tree to
build a bitmap of blocks which are dominated by each block.
A variable's spill operand is classed as alive for any blocks that are
dominated by the block it was defined in, until the instruction index
of the spill operand's last use. As such, it may be classified as live
down a branch where the spill operand is never used, however it is safe
since the spill slot won't be re-allocated until after it's last-use
instruction index in any case.
BUG=v8:9684
Change-Id: I772374599ef916f57d82d468f66429e32c712ddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298008
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69108}
This is exactly the same issue as in https://crrev.com/c/2299364 for test-torque.cc
Change-Id: I066d93918c94d0c68278c72d9b60ec92a1c5f68b
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300546
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68897}
... by migrating old-style code
MyObject* obj = new (zone) MyObject(...)
to the new style
MyObject* obj = zone->New<MyObject>(...)
Bug: v8:10689
Change-Id: I55c686bbedfa1fd1955a5927df3f72b366312fd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288867
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68808}
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}
After support for ARCH_PPC was dropped, it became a subset of
ARCH_PPC64. If you compile for ppc64, then you set the ARCH_PPC64
define which also sets the ARCH_PPC define.
To be able to again support ppc (32 bit) those defines should be
split up again.
This commit only splits up the defines but does not introduce a
working ARCH_PPC variant.
Bug: v8:10102
Change-Id: I64e0749f8e5a7dc078ee7890d92e57b82706a849
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989826
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66390}
Function calls can push arguments onto the stack. The consumed stack
slots are not considered by the function-entry stack check, since
initial frame setup only reserves space for local slots, not call
arguments. This CL adds such logic by tracking the maximum pushed
argument count during instruction selection, and adding these slots to
the (existing) stack check offset logic in code generation.
Bug: chromium:1030167
Change-Id: I26a9407cf38009839b1dda2ff0c8ec297c15ed8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002540
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65814}
The maximal unoptimized frame size is calculated during instruction
selection and will be needed during code generation (it will be
applied as an offset to the stack check). Pass the information along
to the code generator through PipelineData.
Bug: v8:9534
Change-Id: Ia72cd70d57c3de2db9fe43d91b9378d8e2ab8a0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762302
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63451}
Automated cleanup which finds patterns of `Node* a = foo` where `foo` is
a TNode expression, and replaces Node* with the appropriate TNode.
Bug: v8:9396
Change-Id: I8b0cd9baf10e74d6e2e336eae62eca6cfe6a9c11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762515
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63335}
powered by a new function Execution::CallWasm and a corresponding,
Turbofan-generated CWasmEntry stub. This entirely sidesteps the
traditional Execution::Invoke -> JSEntryStub path.
Change-Id: If2b97825cca4ce927eecbddc248c64782d903287
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660618
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62424}
This CL was generated by an automatic clang AST rewriter using this
matcher expression:
callExpr(
callee(
cxxMethodDecl(
hasName("operator->"),
ofClass(isSameOrDerivedFrom("v8::internal::Object"))
)
),
argumentCountIs(1)
)
The "->" at the expression location was then rewritten to ".".
R=jkummerow@chromium.orgTBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org
Bug: v8:9183, v8:3770
No-Try: true
No-Tree-Checks: true
Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61764}
This method is rarely used, and has several problems:
1) It CHECKs that the value is not undefined, then creates a
{Handle<T>} which again DCHECKs that the value is of type {T}.
2) It is called on a raw {FixedArray} but returns a handle.
3) It is often used when no handle is actually needed, adding
unnecessary overhead.
4) It adds complexity and hides actual checks and handlification.
This CL removes that method, replacing some uses by explicit CHECKs (in
tests) and relying on the DCHECKs in the casts otherwise.
R=mstarzinger@chromium.org
Bug: v8:9183
Change-Id: I90ff59e8b78c909a9a207029d8cc9ab16c0c7b56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621939
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61710}
With very few exceptions, this verifies all skipped write-barriers in
CSA and Torque, showing that the MemoryOptimizer together with some
type information on the stored value are enough to avoid unsafe skipped
write-barriers.
Changes to CSA:
SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
MemoryOptimizer by default.
Type information about the stored values (TNode<Smi>) is exploited to
safely skip write barriers for stored Smi values.
In some cases, the code is re-structured to make it easier to consume
for the MemoryOptimizer (manual branch and load elimination).
Changes to the MemoryOptimizer:
Improve the MemoryOptimizer to remove write barriers:
- When the store happens to a CSA-generated InnerAllocate, by ignoring
Bitcasts and additions.
- When the stored value is the HeapConstant of an immortal immovable root.
- When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
- Fast C-calls are treated as non-allocating.
- Runtime calls can be white-listed as non-allocating.
Remaining missing cases:
- C++-style iterator loops with inner pointers.
- Inner allocates that are reloaded from a field where they were just stored
(for example an elements backing store). Load elimination would fix that.
- Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
We could handle that in Torque.
- Double-aligned allocations, which are not lowered in the MemoryOptimizer
but in CSA.
Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
can be handled by overload resolution (in Torque and C++).
Reland Change: Support pointer compression operands.
R=jarin@chromium.orgTBR=mvstanton@chromium.org
Bug: v8:7793
Change-Id: I84e1831eb6bf9be14f36db3f8b485ee4fab6b22e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612904
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61522}
FATAL() calls with more than one argument are preserved.
The rest of chrome does this as well. Stack traces and minidumps should
be sufficient for analyzing the reason for crashes.
This saves 110kb for Android arm32.
Bug: chromium:958807
Change-Id: I88a1ec82f1ed7bd5e7dbccf6d645d5584f16de82
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1598159
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61426}
Everything after UNREACHABLE is dead code, so it makes sense to remove them.
Bug: v8:9183
Change-Id: If76468a73b926d74717cc2348fd5b36d30f680c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605727
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61411}
This reverts commit da7322c05f.
Reason for revert: Breaking the pointer compression bots, e.g.:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3047
Original change's description:
> [csa] verify skipped write-barriers in MemoryOptimizer
>
> With very few exceptions, this verifies all skipped write-barriers in
> CSA and Torque, showing that the MemoryOptimizer together with some
> type information on the stored value are enough to avoid unsafe skipped
> write-barriers.
>
> Changes to CSA:
> SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
> MemoryOptimizer by default.
> Type information about the stored values (TNode<Smi>) is exploited to
> safely skip write barriers for stored Smi values.
> In some cases, the code is re-structured to make it easier to consume
> for the MemoryOptimizer (manual branch and load elimination).
>
> Changes to the MemoryOptimizer:
> Improve the MemoryOptimizer to remove write barriers:
> - When the store happens to a CSA-generated InnerAllocate, by ignoring
> Bitcasts and additions.
> - When the stored value is the HeapConstant of an immortal immovable root.
> - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
> - Fast C-calls are treated as non-allocating.
> - Runtime calls can be white-listed as non-allocating.
>
> Remaining missing cases:
> - C++-style iterator loops with inner pointers.
> - Inner allocates that are reloaded from a field where they were just stored
> (for example an elements backing store). Load elimination would fix that.
> - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
> We could handle that in Torque.
> - Double-aligned allocations, which are not lowered in the MemoryOptimizer
> but in CSA.
>
> Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
> can be handled by overload resolution (in Torque and C++).
>
> R=jarin@chromium.org
> TBR=mvstanton@chromium.org
>
> Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61016}
TBR=mvstanton@chromium.org,jarin@chromium.org,tebbi@chromium.org
Change-Id: I36877cd6d08761726ef8dce8a3e3f2ce3eebe6cf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585732
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61038}
With very few exceptions, this verifies all skipped write-barriers in
CSA and Torque, showing that the MemoryOptimizer together with some
type information on the stored value are enough to avoid unsafe skipped
write-barriers.
Changes to CSA:
SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
MemoryOptimizer by default.
Type information about the stored values (TNode<Smi>) is exploited to
safely skip write barriers for stored Smi values.
In some cases, the code is re-structured to make it easier to consume
for the MemoryOptimizer (manual branch and load elimination).
Changes to the MemoryOptimizer:
Improve the MemoryOptimizer to remove write barriers:
- When the store happens to a CSA-generated InnerAllocate, by ignoring
Bitcasts and additions.
- When the stored value is the HeapConstant of an immortal immovable root.
- When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
- Fast C-calls are treated as non-allocating.
- Runtime calls can be white-listed as non-allocating.
Remaining missing cases:
- C++-style iterator loops with inner pointers.
- Inner allocates that are reloaded from a field where they were just stored
(for example an elements backing store). Load elimination would fix that.
- Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
We could handle that in Torque.
- Double-aligned allocations, which are not lowered in the MemoryOptimizer
but in CSA.
Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
can be handled by overload resolution (in Torque and C++).
R=jarin@chromium.orgTBR=mvstanton@chromium.org
Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61016}
This avoids confusion with the code that is being generated.
R=sigurds@chromium.org
Change-Id: Icb5bd417ca8502553af201654cca1419b9eac87d
Reviewed-on: https://chromium-review.googlesource.com/c/1462001
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59522}
This basically adjusts reality to match our expectations. Methods based
on Code::kConstantPoolOffset expected the constant pool to be located
immediately following the handler table and before the code comments
section, while it was actually emitted before the jump table. We did
not notice earlier since this is only relevant on ppc.
Bug: v8:8758
Change-Id: I189af491fe133a7dc480ff4056372ba7a27faa81
Reviewed-on: https://chromium-review.googlesource.com/c/1445880
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59299}
As far as I can tell these were unused; their only callers were arm
and ppc simulators, but codegen explicitly returned nullptr if in a
simulator build, falling back to std::sqrt.
There's more potential cleanup to be done here for other functions
defined in codegen-*.cc files.
Tbr: clemensh@chromium.org
Bug: v8:7777, v8:8675
Change-Id: I4b9d6062c6724a810ab094d09e3cd04a0b733d9b
Reviewed-on: https://chromium-review.googlesource.com/c/1405851
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58740}
Previosly, LoadArrayElement assumed that the array is a FixedArray.
The PropertyArray and WeakFixedArray pretended to be a FixedArray and
had static asserts about length offsets.
This patch make LoadArrayElement generic and uses a new LoadArrayLength
function to fetch the length of the array without hard-coding the length
offset.
Bug: v8:8486
Change-Id: Ib27132bf3fcecc135ad632c4227c57ca0a05036f
Reviewed-on: https://chromium-review.googlesource.com/c/1346498
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57723}
This CL implements an assembly order optimization that moves blocks
that end a loop with an unconditional backedge to the beginning of
the loop, saving a branch.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I8a5d25f5472d71227af0f623277ea8d0a8d69867
Reviewed-on: https://chromium-review.googlesource.com/c/1335944
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57572}
This CL splits the backend of TurboFan off into its own directory,
without changing namespaces. This makes ownership management a bit
more fine-grained with a logical separation.
R=mstarzinger@chromium.org,jarin@chromium.org,adamk@chromium.org
Change-Id: I2ac40d6ca2c4f04b8474b630aae0286ecf79ef42
Reviewed-on: https://chromium-review.googlesource.com/c/1308333
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57437}
This is a reland of a31a623047
Original change's description:
> [ia32] Remove poisoning logic on ia32
>
> Poisoning has been disabled by default on ia32 a while ago. This CL
> removes its logic from ia32 code generation, which will let us move
> towards fuller (and unconditional) root register support.
>
> Bug: chromium:860429, v8:8254
> Change-Id: I8f672cf48a6ffc7bf21e7794c1b7463d7f8b9594
> Reviewed-on: https://chromium-review.googlesource.com/c/1296131
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56978}
Tbr: mstarzinger@chromium.org,jarin@chromium.org
Bug: chromium:860429, v8:8254
Change-Id: Ia65ac57fdc6b9a0f59cc64455d6a000005e9be3b
Reviewed-on: https://chromium-review.googlesource.com/c/1299080
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56984}
The first: we allocated within the argument list of a function call on
a handlified receiver. The allocation may trigger GC which leaves us
with a stale receiver reference.
The second: in generated code we triggered further allocations while
an uninitialized fixed array was live.
Bug: v8:8145
Change-Id: If59cab6274277534b2ff6463daa5863b8feae22c
Reviewed-on: https://chromium-review.googlesource.com/1213162
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55717}
The WasmCompilationData was a struct that served as an input/output
mechanism for communicating with the code generator. In particular,
it contained a flag for enabling runtime exception for WASM in the code
generator and it also gathered the protected instruction info from
the code generator to be communicated to the WasmCodeManager.
This CL inlines the exception support flag into OptimizedCompilationInfo
and the protected instruction information into the code generator,
along the lines of other flags and data structures created by the
code generator.
R=mstarzinger@chromium.org
Change-Id: If436636067f1a829a095310a73045fe3301cb694
Reviewed-on: https://chromium-review.googlesource.com/1186409
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55358}
With ReadOnlyRoots and GetIsolate on JSReceiver, we can remove almost
every isolate parameter from <Object>::Print. The remaining ones, like
Map, are special-caseable for read-only maps, and as a result we can
remove isolate parameters from <Object>::Print entirely.
This patch also opportunistically cleans up a few places where isolates
were only needed for Object::Print, such as TransitionAccessors and
DescriptorArrays.
TBR=yangguo@chromium.org,mstarzinger@chromium.org
Bug: v8:7786
Change-Id: Id44bd53b9893e679eea5f37b9548257595a1bfd9
Reviewed-on: https://chromium-review.googlesource.com/1133385
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54401}
