This CL relands the implementation of the __getLocal and __sbrk APIs of
the evaluator interface reverted in efea740. Update the original
commit to account for a changes to the import function name tracking and
defaulting to debugging with liftoff.
Change-Id: I9674aad419fb1dab0a9ecbb5d3fd4c33186b127a
Bug: chromium:1020120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151353
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67178}
This cleans up several parts of the tiering logic.
1) Instead of using the {ExecutionTier} to specify whether we do tier up
or down, we introduce a new {TieringState} enum and use that
consistently (also where a {bool} was used before).
2) When tiering up or tiering down, always recompile all functions. It's
very unlikely that we can reuse previous code anyway (tiering down is
cheap enough to just always do it, and when tiering up we need to
recompile everything anyway).
3) Remove the {WasmEngine::RecompileAllFunctions} method and inline the
implementation into callers.
4) Drive-by: Remove some obsolete comments and fix or extend others.
R=thibaudm@chromium.org
Bug: v8:10410
Change-Id: Ic765c6760dd97473ccfd469f22a2514695075587
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151355
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67175}
The existing interface assumed that for atomic binop instructions, the
value register and the result register are the same. However, for x64,
this assumption is not always useful, and for platforms like arm, this
assumption is even negative.
The existing interface was originally introduced because ia32 lacks
registers, and we wanted to avoid platform-specific code in
liftoff-compiler.cc. However, by now the lack of registers on ia32
required us to use platform-specific code also in other places, so
we can also use it for atomic binops and thereby enable a better code
generation.
R=clemensb@chromium.org
Bug: v8:10108
Change-Id: If39cc5f49934422b632bb2a5793c7f5d5d2b65c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150585
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67173}
Trying to write an empty byte array currently invokes undefined behavior
if the byte array is null. That's the case when trying to write an empty
vector for example. Copying zero bytes from nullptr is defined as UB for
memcpy.
Change-Id: I6f7e920c1e19e8b2e3779bbc1c0ad79fc8bd6e98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148789
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67168}
Sometimes we were triggering a wasm code GC at a time where all native
modules just died. Thus, no isolates took part in that GC, and it never
finished (because no isolate would ever call {ReportLiveCodeForGC}).
This never-ending GC would then block all other GCs for the rest of the
life of this wasm engine.
This CL fixes this by just finishing the GC immediately if no isolates
are outstanding.
R=ahaas@chromium.org
Change-Id: I4c25dd6ba4132cf9f72de39c30da5d5cba0526ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150588
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67154}
Port 4558c1dfc5https://crrev.com/c/2141654
Original Commit Message:
As a drive-by, the order of rounding_average_u is adjusted according to
src/wasm/wasm-opcodes.h.
Change-Id: Ia2d39753f618f10e0795f83daa7e5a63f49f554a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2147578
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#67136}
When memory.grow was executed concurrently on multiple threads a data
race could happen such that two memory.grow operations result in the
same return value. With this CL the return value of memory.grow is
unique, given that memory.grow actually grows the memory.
As a concrete example, assume a shared WebAssembly memory initially has
a size of 100. Assume two threads call memory.grow concurrently with a
parameter `10`. Then with the existing code, memory would grow correctly
to a size of 120, but the data race may cause both memory.grow
operations to return 100. With the change in this CL one memory.grow
operation would return 100, the other would return 110.
R=gdeepti@chromium.orgCC=rreverser@google.com
Bug: chromium:1067621
Change-Id: Ib22b5135714a56799e0818ccb39e5dce327e5f8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144113
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67135}
The CL also mooves the {ClearRegister} function to the
platform-independent LiftoffAssembler code.
R=clemensb@chromium.org
Bug: v8:10108
Change-Id: Ibf9f1829a525c859ad004636f678b82aa72d39ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2129637
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jacob Bramley <jacob.bramley@arm.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67126}
This reverts commit f2ea42d6b8.
Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10634
Original change's description:
> [wasm-debug-eval] Implement additional evaluator API methods
>
> This CL implements the __getLocal and __sbrk APIs of the evaluator
> interface. Also includes a drive-by fix of the imports' module: put
> them on the "env" module.
>
> Change-Id: Ie16d1b1cf924b88734eda184d1ce98d52f32f828
> Bug: chromium:1020120
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132786
> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67122}
TBR=jkummerow@chromium.org,pfaffe@chromium.org
Change-Id: I23b078d37971e083c08c9b83994bbf38ac13f103
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1020120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148787
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67124}
We were still occasionally failing tests because sometimes non-debug
Liftoff code was published *after* debug Liftoff code. This would
overwrite the debug code and we would not stop on function entry then.
This fixes this by only preferring Liftoff code in publishing if it has
been compiled for debugging.
As a side effect, this will also prefer TurboFan code which has been
compiled for debugging (i.e. Liftoff bailed out), but this would only
happen for experimental features and in this case we will just overwrite
TurboFan code with TurboFan code, which is fine.
R=thibaudm@chromium.org
Bug: v8:10410
Change-Id: I6516e9f474f6118f0f0c077e6789f604ca128e74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144122
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67123}
This CL implements the __getLocal and __sbrk APIs of the evaluator
interface. Also includes a drive-by fix of the imports' module: put
them on the "env" module.
Change-Id: Ie16d1b1cf924b88734eda184d1ce98d52f32f828
Bug: chromium:1020120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132786
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67122}
This adds a flag to {WasmCode} objects to store whether this code was
generated for debugging. This flag can be set for Liftoff code (in which
case the code will e.g. have an extended prologue for debugging), but it
can also be set for TurboFan, in case Liftoff bailed out when producing
the debugging code.
Having this flag allows us to remove the hack to pass the compilation
results to {OnFinishedUnits} just to check whether we actually wanted to
compile Liftoff functions.
Drive-by: Replace the {ReachedRecompilationTierField} by a
{MissingRecompilationField}, because all we need to know is if we are
still waiting for that function to get recompiled.
R=ahaas@chromium.org
Bug: v8:10330,v8:10410
Change-Id: Ia023df8955a60d9f5595a6cb2737e14d83baf716
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142259
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67119}
Before the "debug" flag was stored on the {CompilationEnv}. But each
background compilation task only gets the {CompilationEnv} once when
starting compilation, so by the time it picks up the "Liftoff for
debugging" compilation jobs, it might still compile them without the
debug flag being set. This leads to flakes in the "debug-step-into-wasm"
test, because we won't stop in the function prologue when stepping in
(because the function prologue does not check the "hook on function
call" flag if debug mode was not enabled).
This CL does not increase the size of a compilation unit, since both the
tier and the debug flag only need a single byte each.
As a nice side effect, this change allows us to remove the lock in
{CreateCompilationEnv}, because no modifyable flag is read any more.
R=thibaudm@chromium.org
Bug: v8:10410
Change-Id: Ic296ea0c4dd1d4dedde119f0536e87e5d301b5a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144116
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67115}
As a drive-by, the order of rounding_average_u is adjusted according to src/wasm/wasm-opcodes.h.
Bug: v8:9909
Change-Id: Ia3a2ed5869f8df8a2191afa034e0b9438de98bc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2141654
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhiguo Zhou <zhiguo.zhou@intel.com>
Cr-Commit-Position: refs/heads/master@{#67104}
v8.1 has a stability issue where we free code too early. Thus disable
for now, such that we can merge this back to v8.1.
v8.2 does not have this problem, since https://crrev.com/c/2078583 fixed
it. This CL is not easily backmergable though.
R=tebbi@chromium.org
Bug: chromium:1070199, chromium:1070182
Change-Id: I4bf468b3e7b5b1e66b314907f844d4195b3ff029
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144966
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67103}
Port 04b6e0de24https://crrev.com/c/2135074
Original Commit Message:
This reorders the SIMD opcodes together with their implementations
on x64, ia32 according to src/wasm/wasm-opcodes.h.
Change-Id: I82c8b678eb65b616d02d20333d479ee4ae0564d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2143974
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#67094}
This is a reland of f902ef3257
Original change's description:
> [wasm] Cleanup wasm script creation
>
> - Do not expose CreateWasmScript since we should now use
> WasmEngine:GetOrCreateScript instead,
> - Initialize all Script fields in CreateWasmScript, not in
> WasmModuleObject::New,
> - Do not pass code size estimate argument, since we can always use the
> actual native module's committed code space.
>
> R=clemensb@chromium.org
>
> Bug: v8:10349
> Change-Id: If9250d62ffc271ab6efc3b9c45958a305c9d1827
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135633
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67083}
Bug: v8:10349
Change-Id: I38c8b6beb07a1e5d565c6a5fd749daea147817bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144064
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67087}
This reverts commit f902ef3257.
Reason for revert: Makes gc-stress unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/27404
Original change's description:
> [wasm] Cleanup wasm script creation
>
> - Do not expose CreateWasmScript since we should now use
> WasmEngine:GetOrCreateScript instead,
> - Initialize all Script fields in CreateWasmScript, not in
> WasmModuleObject::New,
> - Do not pass code size estimate argument, since we can always use the
> actual native module's committed code space.
>
> R=clemensb@chromium.org
>
> Bug: v8:10349
> Change-Id: If9250d62ffc271ab6efc3b9c45958a305c9d1827
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135633
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67083}
TBR=clemensb@chromium.org,thibaudm@chromium.org
Change-Id: Iac2978af1a300ec079baebab0feb8c9598711738
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10349
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144058
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67085}
- Do not expose CreateWasmScript since we should now use
WasmEngine:GetOrCreateScript instead,
- Initialize all Script fields in CreateWasmScript, not in
WasmModuleObject::New,
- Do not pass code size estimate argument, since we can always use the
actual native module's committed code space.
R=clemensb@chromium.org
Bug: v8:10349
Change-Id: If9250d62ffc271ab6efc3b9c45958a305c9d1827
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135633
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67083}
Templates provide better error messages and make debugging easier.
R=zhin@chromium.org
Bug: v8:10364
Change-Id: Ia3581c4458e8edb3b24371605000b0b00bb5069d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2140936
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67081}
This increases source code size, but the code is simple and repetitive.
Complexity is reduced by removing the macros.
R=zhin@chromium.org
Bug: v8:10364
Change-Id: I989c4d78aaebe00c7fbb525d88a6670cd0fe3b92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2141732
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67078}
This fixes an issue in WasmScript::ClearBreakPoint, which is was still removing
breakpoints in the interpreter, even when debugging in Liftoff.
The existing test inspector/debugger/wasm-stepping-liftoff.js does not require
any changes.
Change-Id: I5c60839ffde91cdd11d9f808a3102f2cc1324087
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2136872
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#67065}
This reorders the SIMD opcodes together with their implementations
on x64, ia32 according to src/wasm/wasm-opcodes.h.
Bug: v8:9909
Change-Id: Ib2e75927b3b44ebc951005222c8641c256d8872c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135074
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhiguo Zhou <zhiguo.zhou@intel.com>
Cr-Commit-Position: refs/heads/master@{#67051}
The compare operations pass a hard-coded first argument to the emit
function. Instead of implementing this via a lambda, put it in a separate
{BindFirst} helper, similar to {std::bind_front} (C++20).
R=zhin@chromium.org
Bug: v8:10364
Change-Id: If48c87a3df5ea6fa2b155873e4586af5d6b21119
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139580
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67047}
This is to avoid a lock inversion problem. In many situation, the
{NativeModule} lock is held while getting the {DebugInfo} lock.
Hence we should never do is the other way around, otherwise we risk a
deadlock.
When setting a breakpoint, we hold the {DebugInfo} lock when triggering
recompilation, but recompilation accesses the {NativeModule} for
creating the {CompilationEnv}, and therefore takes the {NativeModule}
lock.
This CL fixes this lock inversion by giving up the {DebugInfo} lock
before recompiling functions.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: Ic818c6589b2b532006aee4c16bac92b2fe79fa65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139574
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67042}
This removes the stack from the local scope, as the stack is now
in its own scope.
Bug: chromium:1043034
Change-Id: I595604da71ecf4362ef67134ade8b3987086d258
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2128049
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67038}
Currently, only one memory is supported.
For memory, we would use name as follows.
1. If import: use <import_module>.<field_name> from WasmImport.
2. If export: use <field_name> from WasmExport.
3. Use memory<index>.
Doc: https://docs.google.com/document/d/1XoXWONLBgZWQ9dhtoMpQPvD0fnnWA50OorsuSXfME3g
Bug: v8:10242
Change-Id: Ifd342bcd86ac302f5b43f2ee88a8ea21a28b5a0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132724
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67020}
This shrinks the WasmCode a bit more (to the minimum which is currently
required) and at the same time makes space for more flags to be stored
in a bitfield.
R=ahaas@chromium.org
Bug: v8:10254
Change-Id: I98a24e917a00d74dd2306f18d45525e82b245826
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135738
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67015}
If there is still Liftoff code installed on a function, we cannot reuse
it when tiering down, since we don't know if it was compiled with
debugging capabilities. This made the "debug-step-into-wasm" test flake.
R=thibaudm@chromium.org
Bug: v8:10368
Change-Id: I3672940015c85ec10ead2e33e7792410b47589d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135732
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66993}
Instead of two copies of the lookup code in frames.cc and wasm-debug.cc,
put one lookup method on the WasmCode. This is where it belongs really,
since the WasmCode is the main input to the function (besides the
offset).
Also refactor how source positions are computed in WasmCompiledFrame.
Avoid going through the summary, which is unneccessarily complex. This
also adds another {byte_offset} accessor which can be used for
debugging.
Bug: v8:10235
Change-Id: I5c545ee302754b86009f09bedc5ff6e39ba664f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135726
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66991}
Adding code can happen in parallel (it includes copying the code to the
code region and relocation it). Publishing happens under one lock per
native module though. We eventually want to avoid blocking on this lock
for too long. This CL prepares that by splitting the actions of adding
and publishing code.
R=ahaas@chromium.org
Bug: v8:10330, v8:10387
Change-Id: Iddbdadfe32e691bbf5e7b387ea947579bc3376f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134372
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66979}
For easier debugging of Liftoff code generation issues, add code
comments or out-of-line code.
The name is generated from the {RuntimeStubId}. The respective name
accessor is currently defined on the {NativeModule}, this CL makes it a
top-level function so we can reuse it from Liftoff.
R=thibaudm@chromium.org
Bug: v8:10235
Change-Id: I7b99779217b9c052e34ad132eb34859b20548092
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134307
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66978}
i64x2 mul is more tricky, the algorithm is slightly modified:
- for arm64, we can only use 2 temporaries
- for arm, we only have 1 temporary, so we get another register
manually, if we need it (modify lhs/rhs if they are not used)
Bug: v8:9909
Change-Id: I0398e2c95348a8b49ca9773a78ccfb7af73e2eef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2128606
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66971}
Port a1bd722799https://crrev.com/c/2129631
Original Commit Message:
This is the same cleanup as in the previous CL, but for {EmitBinOpImm}.
This requires a minor change in the name of the emit functions with
immediate, to make them distinguishable from the emit functions with two
registers. We just append an "i" to the functions with immediate.
Change-Id: I5089097cb74e204002f0dfcfb6ed10d3ade4da0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132346
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#66959}
This inlines the first set of macros in order reduce an unneccessary
layer of abstraction. This makes the code easier to read and to debug.
R=zhin@chromium.org
Bug: v8:10364
Change-Id: Ia8ccb90c285c365ae5b3d52b6b6912ad1a76d81d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2129532
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66945}
Import the most commonly used ValueType kinds as constants into
{LiftoffCompiler}, so that we don't need the fully-qualified accessor on
{ValueType}.
This makes many template instantiations much shorter and hence easier to
read.
Drive-by: Replace break after function by return. This often saves
another line, making macros and switch statements much shorter.
R=zhin@chromium.org
Bug: v8:10364
Change-Id: If78352c2fa6b854989fa82718d0b3478b4d73aad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2129634
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66943}
This is the same cleanup as in the previous CL, but for {EmitBinOpImm}.
This requires a minor change in the name of the emit functions with
immediate, to make them distinguishable from the emit functions with two
registers. We just append an "i" to the functions with immediate.
R=zhin@chromium.org
Bug: v8:10364
Change-Id: Ie3732a956698368a5f1fbe67334a13014cd2f354
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2129631
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66941}
Liftoff has lots of macros that just convert between {LiftoffRegister}
and either {Register} or {DoubleRegister}.
This CL avoids most of these lambdas by passing the original assembler
function to {EmitUnOp} and {EmitBinOp}, and converting the register
types only when calling the respective function.
This makes the code in many macros a lot shorter, and might allow us to
eliminate many macros and just inline their code.
R=zhin@chromium.org
Bug: v8:10364
Change-Id: I8b7dbb19e367d33181d94472ab422a0a50786449
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2129629
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66938}
If we want external people to stop shouting WASM, we should start
by avoiding that in our own code base.
This CL replaces almost all occurrences of "WASM" by "Wasm". The
last remaining ones (in frames.cc) are in capitalized contexts where
WASM fits.
TBR=ecmziegler@chromium.org
Bug: v8:10155
Change-Id: I905b92220768b99bb5e1165255691ffe4498dba3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126917
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66917}
For globals, we would use name as follows.
1. If import: use <import_module>.<field_name> from WasmImport.
2. If export: use <field_name> from WasmExport.
3. Use global<index>.
Add DecodeGlobalNames similar to DecodeFunctionNames.
Doc: https://docs.google.com/document/d/1XoXWONLBgZWQ9dhtoMpQPvD0fnnWA50OorsuSXfME3g
Bug: v8:10242
Change-Id: I11131528fc6ae6ca50727e9b428f76e76b0000e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122523
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66910}
When stepping in from JS, the stepping frame ID will not be set.
Instead of ensuring to set it properly, we can just skip the check for
the frame ID. It was needed before, when we didn't properly reset
stepping information. Now, it's redundant anyway.
Also, ensure that we don't redirect to the interpreter if the
--debug-in-liftoff flag is set.
Drive-by: Fix and clang-format some parts of the test (no semantic
change).
R=thibaudm@chromium.org, szuend@chromium.org
Bug: v8:10351
Change-Id: I58a3cd68937006c2d6b755a4465e793abcf8a20c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124317
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66904}
All 6 replace_lane operations for ARM and ARM64.
Changes to wasm-compiler required for ARM (where register aliasing is
different - 2 fp registers map to 1 simd register). When src2_rc is
kFpReg, and src1_rc is kFpRegPair, we still need to pin src2 when
getting a register for src1, since the registers can overlap. (On other
backends, src1_rc == src2_rc == kFpReg, so the current condition is met,
and we correctly pin src2). Same for result_rc and src2_rc.
Bug: v8:9909
Change-Id: Ib39b71534290a7109fb0da4bf62dabc66460a0dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117637
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66893}
DebugInfo::RemoveBreakpoint did not remove the correct breakpoint
because of a confusion between offsets relative to the function and
offsets relative to the module. This is not visible in the tests, as
removed breakpoints are already skipped by the runtime function.
Drive-by: replace a return which should have been a continue in OSR.
R=clemensb@chromium.org
Change-Id: I574c474139e969bd91217cfa7adc806d43db3c99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120589
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66891}
This patch changes the order in which stack values are shown
in the stack scope. As a result, changes to the stack show up
at the end of the stack.
Bug: chromium:1043034
Change-Id: I735fc29d3957b6484589554ce046114e1b7bd9e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122987
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66884}
Most control structures in WebAssembly do not have a clear execution
semantics, they are more like markers. Hence the execute state, and the
change in the state, when breaking on them and stepping over them is
unclear.
Hence this CL just makes them non-breakable. If the user tries to set a
breakpoint on them, this breakpoint will automatically be propagated to
the first instruction after the respective control opcode (this is
tested for other cases in existing tests).
R=thibaudm@chromium.org
Bug: v8:10326
Change-Id: Iaf540a94789c9cbc87d23ddfb794e4b01776b49f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122017
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66876}
The top wasm frame position can be inaccurate after removing a
breakpoint and OSRing the new code. This is because we are missing the
source position which was associated with that breakpoint in the old
code. Fix this by explicitly introducing the missing source position.
R=clemensb@chromium.org
Change-Id: I0d18061c4c2411de8d2ccaaebbb4eb550a4c3160
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120591
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66871}
This change adds a stack scope for wasm debugging.
Currently the local scope contains both local variables as well as
the expression stack. For now, this change duplicates the information
available on stacks into the stack scope, until we have added
support for the stack scope in the DevTools front-end.
Bug: chromium:1043034
Change-Id: Ib0a07e07be7c53003526a7b1e1dbfaa1116b41ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093510
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66867}
A StepOver at a return (either explicit return instruction, or implicit
return at the end of the function) should stop again in the caller
frame.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: I313e6b612ac52e73b33ef07c6da1ced2aa0db600
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110250
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66852}
This fixes issues with replacing the return address of deeper (non-top)
wasm frames, i.e. frames which are at a call position. The replaced
address should also point after the call in the new code, so we don't
execute the same call again.
This is achieved by using slightly different encodings for breakpoint
positions and other (wasm instruction) positions. Breakpoints set
{is_instruction} to {false} in the source position table entry, whereas
usual wasm instruction set it to {true}.
Also, during stack walking for OSR, we remember whether we want to OSR
to the position before the instruction (if it's the top frame), or after
the call instruction (if it's deeper in the stack). We then use the
{is_instruction} predicate to find the right location.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: I73212a7532c6ecf4c82bde76fe4059c8203e422c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116206
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66850}
We have similar logic in place when allocating wasm memory fails. For
growing, we also need to hard-abort the program, because it would cause
observable differences in program behaviour otherwise.
R=ahaas@chromium.org, machenbach@chromium.org
Bug: chromium:1063951
Change-Id: I98f3b5364100900fce0e6553a347155a39923ca6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116036
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66842}
We previously could not OSR a frame paused in a breakpoint with another
frame in which the same breakpoint was removed, because the latter was
missing the source position.
This change fixes this by iterating the stack to collect frame
positions, and emitting the corresponding source positions in Liftoff.
R=clemensb@chromium.org
Bug: v8:10321,v8:10147
Change-Id: I5a7950d5ce6e3cd5a0648b861db75f4f3dafa644
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2115433
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66830}
Close WasmCodeRefScope before we potentially free the native module in
UpdateNativeModuleCache.
R=clemensb@chromium.org
Bug: chromium:1062868
Change-Id: I7cd11fd2283a2cc399d05e32c609ff1af07e2706
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113380
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66829}
The behaviour was clarified in the spec:
https://github.com/WebAssembly/exception-handling/pull/97
br_on_exn (and also rethrow, which will be added in another CL) should
trap on nullptr. This CL implements this by an explicit check on each
br_on_exn (within {GetExceptionTag}). This check will be redundant if
several br_on_exn follow each other. Since also the runtime call for
{GetExceptionTag} is redundant, and also the fact that we do a runtime
call is suboptimal, I consider the whole implementation prototypical for
now anyway.
R=jkummerow@chromium.orgCC=aheejin@chromium.org
Bug: v8:10128
Change-Id: I234c3183f93fe0884aadd2ab6dbd6c2b7a07c660
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113381
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66826}
Remove unused breakpoints as we hit them. OSR in this case does not work
properly yet, because we are missing the source position for the removed
breakpoint in the new code.
R=clemensb@chromium.org
Bug: v8:10321
Change-Id: I908546c1b37ca044166b24b4900126ab79f117ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111216
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66821}
This CL provides a generic way to prepare a builtin call: The
{PrepareBuiltinCall} takes the builtin signature for 64-bit systems,
the CallDescriptor, and a Vector of VarStates for the parameters, and
moves all parameters to their correct place, which is either in a
register or on the stack.
To test the new code this CL adjusts the implementation of AtomicWait
to use PrepareBuiltinCall. Thereby AtomicWait is now also supported
on 32-bit platforms, including ia32.
R=clemensb@chromium.org
Bug: v8:10108, v8:10281
Change-Id: Ia8589166310ea2e8442531b4ed20db62d7b4aff0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108554
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66810}
This CL introduces a CSA builtin for the TableCopy instruction. This
builtin allows to generate smaller code for both TurboFan and Liftoff,
and easier code generation from Liftoff.
The smaller code size comes from:
* Parameters are passed through registers, not the stack.
* Lower number of parameters: the call target, number of parameters, and
context are not passed as parameters.
* No int to smi conversion in generated code.
R=clemensb@chromium.org
Bug: v8:10281
Change-Id: I4734b94c8a2aff08a5938504e3e36d0d2424f8ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110010
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66797}
Implement i8x16.bitmask, i16x8.bitmask, i32x4.bitmask on interpreter and
arm64.
These operations are behind wasm_simd_post_mvp flag, as we are only
prototyping to evaluate performance. The codegen is based on guidance at
https://github.com/WebAssembly/simd/pull/201.
Bug: v8:10308
Change-Id: I835aa8a23e677a00ee7897c1c31a028850e238a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2099451
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66793}
This CL introduces a CSA builtin for the TableInit instruction. This
builtin allows to generate smaller code for both TurboFan and Liftoff,
and easier code generation from Liftoff.
The smaller code size comes from:
* Parameters are passed through registers, not the stack.
* Lower number of parameters: the call target, number of parameters, and
context are not passed as parameters.
* No int to smi conversion in generated code.
The CL also introduces a small CSA function which takes an uint32 value
and a max value as parameters and returns a Smi of the minimum of these
two.
R=clemensb@chromium.org, ishell@chromium.org
Bug: v8:10281
Change-Id: I40f248c20ec76e6ae9483a5e2907a68f42f2cb04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106201
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66792}
Add some more code comments for code snippets that are not obvious,
especially if debug code is enabled.
The comments help when looking at Liftoff code for debugging code
generation issues.
R=thibaudm@chromium.org
Change-Id: I566bf2b05a454fb8addc030359969d36cb2cb707
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108557
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66791}
Update the "hook on function call" flag also in the wasm case, and
slightly change the {IsStepping} logic to stop in any frame if the last
step action was anything other than StepNext.
In future CLs, this has to be extended further for StepOut and for
StepOver at a return location.
When that is done, we can also reenable more stepping in the test.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: Ib3aa8c2c2e137690140e5879a33e2bcc340821e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108035
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66789}
This implements the first part of WebAssembly debug evaluate. The patch
includes the foundation required to execute evaluator modules. It only
implements the first of the APIs of the evaluator module spec.
Bug: chromium:1020120
Change-Id: I06ec98a63d0a0ec8d81c2eac4319c4b85d3e16c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089936
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66787}
Without the nops, the PC after the call might be the same as the PC of
the next instruction, and we might emit two different source positions
for the same PC.
This will not be the final solution, see attached bug.
R=thibaudm@chromium.org
Bug: v8:10337
Change-Id: I8c893d8d7ad00684ec6e1bc7f6c00f649695029f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108029
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66775}
This extends the Liftoff function prologue in the debug case. It now
checks the "hook on function call" flag, and if that flag is set, it
triggers a breakpoint.
The address of that flag is stored in the WasmInstanceObject for fast
access.
Drive-by: Add an output operator for ValueType, which helps with
debugging.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: I572de802815259ee0ef0df9b22ce30b510b4e30d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106211
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66774}
In the runtime, we always had a convention to use int-typed accessors
for Smi fields. For Torque-generated classes, we kept them Smi-typed
but then added int wrappers around that.
This CL makes Torque generate int-typed accessors directly, removing the
need for these wrappers.
TBR=hpayer@chromium.org
Bug: v8:7793
Change-Id: I348e1d96295c9676fafda32b7d49088848527f89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106210
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66760}
And fix a few issues revealed by this new test. Incidentally, the test
uses removeBreakpoint which was still untested with Liftoff. But as
expected this seems to work out of the box.
R=clemensb@chromium.org
Bug: v8:10321
Change-Id: Ifa4e867737d925ea8c6c9731575a32f3da3e16dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106206
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66752}
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}
Add a scriptLanguage enum to the new scripts events. This overhauls
crrev.com/c/2011083 that was related. Report the code section offset
as well as the script language on the Debugger.scriptParsed and
Debugger.scriptFailedToParse events.
Bug: chromium:1057569
Change-Id: I40b43f28f0b3e094720db4fc1f07db1a0c293ee0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083025
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66749}
Implement all 8 extract_lane ops on ARM and ARM64.
Bug: v8:9909
Change-Id: I72e30b53c92933bd5830008ec02e1f4526e8b4c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2103169
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66735}
Implement f64x2.add, i64x2.add, i8x16.add on ARM and ARM64.
Bug: v8:9909
Change-Id: Id41bb3c02c1873e1380463264a3e5fd31949c949
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2103107
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66733}
Complete Liftoff support is needed for debugging. In case of a bailout
from Liftoff, produce a better error message, also in release builds.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: I8cdb11a5c54f9101ea611e28dd3fb7dc4fe5c538
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105633
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66730}
The bailout was guarded by the "if (counters)" condition, which does not
make sense.
If Liftoff compilation is executed for debugging, no counters will be
passed. On platforms that do not implement Liftoff, we still need to
bail out correctly.
R=ahaas@chromium.org
Bug: v8:10147
Change-Id: I188460183bb1c376d456e0d4e54e2338f4a66e23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105353
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66725}
This method is called in the critical section in {PublishCode}, hence
performance is important here. Since most modules will only have a
single code space anyway, we can use the main jump table in the vast
majority of cases, and avoid taking a lock and iterating another data
structure.
R=ahaas@chromium.org
Bug: v8:10330
Change-Id: I18cbd3b127172963ccc9ec576a0985e874da7865
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2104891
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66721}
This implements inspection of live registers on breakpoints in Liftoff.
To that end, the frame pointer of the WasmDebugBreak frame is remembered
when iterating the stack. Based on a platform-specific implementation of
{WasmDebugBreakFrameConstants}, the offset of the respective register
within that frame is computed, and the value is read from the frame.
As a drive-by, the wasm debug side table is storing register codes as
liftoff codes, which can also store register pairs (needed for i64 on
32-bit platforms, and for SIMD, which is not supported yet).
R=jkummerow@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10222
Change-Id: I01b669baf56430e100cd46cc46f210121ea679da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102574
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66719}
This CL extracts a function which reads from a buffer and additionally
increments an offset for the next read.
R=clemensb@chromium.org
Bug: v8:10281, v8:10155
Change-Id: Id8d79130cde17053d701d2508e40cba993471e55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101001
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66707}
Doing the bounds check in C++ has the advantage that we generate less
code, and that TurboFan graphs get smaller. Additionally it will make
code generation from Liftoff easier. There is not really a downside:
We already called C++ anyways to do the actual memory.fill operation.
R=clemensb@chromium.org
Bug: v8:10281
Change-Id: If4e36d45a3fd1c4c0fef9137d37097a012e7a409
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100991
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66703}
SignatureHelper::kMarker needs an explicit instantiation after
f3b4167f8b.
Change-Id: Ia5a0696a576a2c59bea262359058bd63eb3c8426
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101004
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66701}
This CL adds memory masking to our implementation of memory.copy and
memory.init when spectre mitigations are enabled.
R=clemensb@chromium.org
Bug: v8:10281
Change-Id: I8722fa7ab244f339d859d5479eceede85dbbd08c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66700}
Port f3b4167f8bhttps://crrev.com/c/2091471
Original Commit Message:
In preparation for adding reference types, which need an additional
parameter to indicate the referenced type.
Change-Id: I1b66bffea3ac2637886673476c8f7d62150b33a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100695
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66699}
Flood functions with breakpoints to prepare them for stepping. With a
small modification to the runtime function, this already implements a
basic step over functionality.
We still cannot resume, step in or step out (including stepping over a
return instruction).
R=clemensb@chromium.org
Bug: v8:10321
Change-Id: Ia4a6335d24c1a511c2f1fc9b48d728f327b3df56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098732
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66697}
In debug builds of Liftoff, the opcode of the next instruction is
printed as a code comment. For multi-byte opcodes, all but the first
byte have to be extracted explicitly from the wasm code in the
{NextInstruction} function. The bounds check for this extraction was
missing.
R=clemensb@chromium.org
Bug: chromium:1061304
Change-Id: I16a05d54e50506c1387970ad84082d7e76108fc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100996
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66696}
This change is based on a discussion from
https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696
wherein Tobias suggested moving the folding away of ==0 operations out
of the platform-specific instruction selectors and into the
MachineOperatorReducer. I noticed that CommonOperatorReducer already
handles some very similar cases, so I have tried putting the ==0 folding
into CommonOperatorReducer instead. I'm happy to move it into
MachineOperatorReducer if that's better; I still don't have a very good
understanding of how roles are separated among reducers.
Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66688}
In preparation for adding reference types, which need an additional
parameter to indicate the referenced type.
Bug: v8:7748
Change-Id: If4023f3d9c7f42ed603b69c43356d2e8b81a0daa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091471
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66687}
On Windows in an asan build we have to reset the thread-in-wasm flag in
the memory_init_wrapper, memory_copy_wrapper, and memory_fill_wrapper.
Accidentally I removed this code for the memory_init_wrapper and the
memory_copy_wrapper recently. This CL introduces the code again.
R=clemensb@chromium.org
Bug: v8:10281
Change-Id: If46def5cd64ac8cbff9b86108189462717961edd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098737
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66686}
x64's cmpxchgl instruction does not zero-extend the register. The stale
high word caused the difference in the results of the interpreter and
Liftoff/TurboFan.
R=clemensb@chromium.orgCC=zhin@chromium.org
Bug: chromium:1059529
Change-Id: I0fd440bee26e25b90b29533cfa9151e4d87754e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098726
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66685}
The return value of {memory_init_wrapper} was defined as {bool} in
the original CL. When compiled with clang, the full return register is
written when {true} or {false} is returned. With msvc, however, the
return value is written as a single byte, without zero-extension. In
generated code, the full return register is used and therefore stale
bytes in the return register caused problems.
With this CL the return value is changed to {uint32_t}. This enforces
zero-extension of the return value and thereby fixes the issue.
R=clemensb@chromium.org
Bug: v8:10281
Change-Id: I1446e51d88a35def56bd39a8336baa81543497bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096627
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66670}
The return value of {memory_copy_wrapper} was defined as {bool} in
the original CL. When compiled with clang, the full return register is
written when {true} or {false} is returned. With msvc, however, the
return value is written as a single byte, without zero-extension. In
generated code, the full return register is used and therefore stale
bytes in the return register caused problems.
With this CL the return value is changed to {uint32_t}. This enforces
zero-extension of the return value and thereby fixes the issue.
R=clemensb@chromium.org
Bug: v8:10281
Change-Id: I628d01cfd7193fa960a7ccdf0d9fd896f510cd3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096626
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66666}
This reverts commit c475e70460.
Reason for revert: Fails on MSVC: https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/12805
Original change's description:
> [wasm] Do memory.copy bounds check in C++ code
>
> In the existing implementation we first did a bounds check in generated
> code, and then called a simple C++ function to do the actual copying.
> With this CL now we pass the WasmInstanceObject to the C++ function in
> addition to the memory.copy parameters. Thereby we can do the bounds
> check in C++, which is much easier, less error prone, and which also
> speeds up code generation and reduces code size. Performance should not
> be worse, because we were already doing the call to C++ anyways.
>
> R=clemensb@chromium.org
>
> Bug: v8:10281
> Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66655}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: Ic2491f635a292e004f6c95498a045ba102138dc5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10281
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096623
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66658}
This reverts commit c7a26b1316.
Reason for revert: Need to revert previous CL because it fails on MSVC: https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/12805
Original change's description:
> [wasm] Do memory.init bounds check in C++ code
>
> In the existing implementation we first did a bounds check in generated
> code, and then called a simple C++ function to do the actual copying.
> With this CL now we pass the WasmInstanceObject to the C++ function in
> addition to the memory.init parameters. Thereby we can do the bounds
> check in C++, which is much easier, less error prone, and which also
> speeds up code generation and reduces code size. Performance should not
> be worse, because we were already doing the call to C++ anyways.
>
> R=clemensb@chromium.org
>
> Bug: v8:10281
> Change-Id: Ia86e1d08001a8bc7556277abeaa9208ec1128f89
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096621
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66656}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I1064113e7f1c445d04652a973c994317fd3e739a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10281
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096624
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66657}
In the existing implementation we first did a bounds check in generated
code, and then called a simple C++ function to do the actual copying.
With this CL now we pass the WasmInstanceObject to the C++ function in
addition to the memory.init parameters. Thereby we can do the bounds
check in C++, which is much easier, less error prone, and which also
speeds up code generation and reduces code size. Performance should not
be worse, because we were already doing the call to C++ anyways.
R=clemensb@chromium.org
Bug: v8:10281
Change-Id: Ia86e1d08001a8bc7556277abeaa9208ec1128f89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096621
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66656}
In the existing implementation we first did a bounds check in generated
code, and then called a simple C++ function to do the actual copying.
With this CL now we pass the WasmInstanceObject to the C++ function in
addition to the memory.copy parameters. Thereby we can do the bounds
check in C++, which is much easier, less error prone, and which also
speeds up code generation and reduces code size. Performance should not
be worse, because we were already doing the call to C++ anyways.
R=clemensb@chromium.org
Bug: v8:10281
Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66655}
Bill kindly pointed out to me that v8windbg was not handling bit_field2
correctly. The issue was that the constexpr type for ElementsKind was,
somewhat unsurprisingly, "ElementsKind", but v8windbg expected a fully-
qualified type name like "v8::internal::ElementsKind". This change
addresses the problem in two ways:
1. Update v8windbg's type resolution logic to resolve type names as if
they were used in the v8::internal namespace. This makes it more
consistent with how those type names are used in other generated
Torque code, reducing surprises and the number of times we have to
write `v8::internal::` in .tq files.
2. Add compile-time verification that any constexpr type name used as a
string in class-debug-readers-tq.cc can also resolve as a type name.
Bug: v8:9376
Change-Id: I349cd6ab586fd8345a1fa8bfc3989bb8e6376ab8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063769
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66633}
When dst is a fp pair, we set both low and high fp regs. Later when we
look at set regs to determine which registers to load into, we examine
both low and high fp. This is wrong - we only need to look at the low
fp, since Fill will load into the correct fp pairs. The bug was
triggered because we were examining into junk values in register_loads
indexed by the high fp.
Fixed: v8:10307
Change-Id: I6cbc212a969090818a5da0fe3dab36a418c23d04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091632
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66632}
String::NewFromLiteral is a templated function that takes a char[N]
argument that can be used as an alternative to String::NewFromUtf8 and
returns a Local<String> rather than a MaybeLocal<String> reducing the
number of ToLocalChecked() or other checks.
Since the string length is known at compile time, it can statically
assert that the length is less than String::kMaxLength, which means that
it can never fail at runtime.
This also converts all found uses of NewFromUtf8 taking a string literal
or a variable initialized from a string literal to use the new API. In
some cases the types of stored string literals are changed from const
char* to const char[] to ensure the size is retained.
This API does introduce a small difference compared to NewFromUtf8. For
a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
would treat this as a 3 character string, whereas the new API will treat
it as a 7 character string.
As a drive-by fix, this also fixes all redundant uses of
v8::NewStringType::kNormal when passed to any of the String::New*
functions.
Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66622}
Implement f64x2, i64x2, i8x16 splats on arm and arm64.
Bug: v8:9909
Change-Id: I41f635ae5c6f025ece7f6445a58fbad1ad678fbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087694
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66616}
Prefixed opcodes do not get written correctly in code comments in
Liftoff. The reason is that only one byte is interpreted as the opcode,
but prefixed opcodes take two bytes. This CL loads the second byte if
necessary.
The change could be done in function-body-decoder-impl.h, but that could
lead to performance regressions: it is a hot code path, and the change
here is just for debugging.
R=clemensb@chromium.org
Bug: v8:10155
Change-Id: I2282c068c81b5b1e2e2ed9757f4e77687d1d4ede
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091467
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66613}
This CL fixes a special case where a WasmExportedFunction is passed to
the WebAssembly.Function constructor. This is a case that was not yet
implemented in V8, and which is also not specified in the proposal yet.
With this CL we do a signature check of the provided function. If it
matches, the function itself is returned. Otherwise a TypeError is
thrown.
I filed an issue: https://github.com/WebAssembly/js-types/issues/13R=jkummerow@chromium.org
Bug: chromium:1057534
Change-Id: Ib09d1ba18abaa6a8dd451aa747fd26c03d927413
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084813
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66610}
All other simple C functions take a pointer to a stack slot which
contains the actual parameters, whereas the memory_copy_wrapper takes
three parameters. This makes the code generation from Liftoff more
difficult. This CL changes the signature of memory_copy_wrapper to match
the signature of other simple C functions.
As MemoryCopy and MemoryInit are already implemented with C calls, this
change should not make a big difference in terms of performance. Simpler
and smaller Liftoff code may have more effect on performance. If this
assumption turns out wrong, we can change it in the future.
R=clemensb@chromium.org
Bug: v8:10281
Change-Id: I39e0ea00fcb22b4e84e612fe58eb4642856b72c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078576
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66607}
This is a reland of 79398ab09d
Original change's description:
> [wasm] Further reduce the size of WasmCode
>
> Also, save dynamic allocations (plus their memory overhead).
> This is realized by storing the relocation information, source position
> table, and protected instruction information together in one "metadata"
> byte array.
> For each of the three components, we just store their size, such that
> the accessors can return the respecitive {Vector} views as before.
>
> This makes each WasmCode object 24 bytes smaller on 64-bit
> architectures. It also saves a few more bytes per code object because
> less padding is needed for the individual allocations, and each dynamic
> allocation comes with some constant memory overhead.
>
> Since the protected instructions will just be stored in a byte array
> now, some APIs are refactored to just return that byte array directly
> (instead of an array of {ProtectedInstructionData}). This also
> simplifies serialization and deserialization, and will allow for
> switching to a more compact representation in the future.
>
> Drive-by: Add some more checks to {Vector::cast} to protect against
> undefined behaviour.
>
> R=ahaas@chromium.org
>
> Bug: v8:10254
> Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66596}
Tbr: ahaas@chromium.org
Bug: v8:10254
Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66598}
This reverts commit 79398ab09d.
Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10186
Original change's description:
> [wasm] Further reduce the size of WasmCode
>
> Also, save dynamic allocations (plus their memory overhead).
> This is realized by storing the relocation information, source position
> table, and protected instruction information together in one "metadata"
> byte array.
> For each of the three components, we just store their size, such that
> the accessors can return the respecitive {Vector} views as before.
>
> This makes each WasmCode object 24 bytes smaller on 64-bit
> architectures. It also saves a few more bytes per code object because
> less padding is needed for the individual allocations, and each dynamic
> allocation comes with some constant memory overhead.
>
> Since the protected instructions will just be stored in a byte array
> now, some APIs are refactored to just return that byte array directly
> (instead of an array of {ProtectedInstructionData}). This also
> simplifies serialization and deserialization, and will allow for
> switching to a more compact representation in the future.
>
> Drive-by: Add some more checks to {Vector::cast} to protect against
> undefined behaviour.
>
> R=ahaas@chromium.org
>
> Bug: v8:10254
> Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66596}
TBR=jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,tebbi@chromium.org
Change-Id: Id80aa82cfce8942879031032b322ee66855b5600
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10254
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089933
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66597}
Also, save dynamic allocations (plus their memory overhead).
This is realized by storing the relocation information, source position
table, and protected instruction information together in one "metadata"
byte array.
For each of the three components, we just store their size, such that
the accessors can return the respecitive {Vector} views as before.
This makes each WasmCode object 24 bytes smaller on 64-bit
architectures. It also saves a few more bytes per code object because
less padding is needed for the individual allocations, and each dynamic
allocation comes with some constant memory overhead.
Since the protected instructions will just be stored in a byte array
now, some APIs are refactored to just return that byte array directly
(instead of an array of {ProtectedInstructionData}). This also
simplifies serialization and deserialization, and will allow for
switching to a more compact representation in the future.
Drive-by: Add some more checks to {Vector::cast} to protect against
undefined behaviour.
R=ahaas@chromium.org
Bug: v8:10254
Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66596}
There was an issue in the register allocation in the original CL. The
register of the new_value did not get pinned, so it was used for the
expected value as well.
Bug: v8:10108
Change-Id: I2589fc31f8fbfda39c94ea5801f63ed370a3b7ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084815
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66579}
Add tier up to existing recompilation logic.
This is a part of Tier up to Turbofan on Debugger.disable
Bug: v8:10290
Change-Id: I44731df520201ac254f2d1bfbfb5c49d8bb50117
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080658
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66573}
The histograms were removed from chrome. This CL cleans up the V8 code
to stop reporting samples.
R=ahaas@chromium.org
Bug: chromium:1053285
Change-Id: I7c6ff36ac9bb5d86e81e5f36849903a95a8ed618
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083478
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66553}
Some opcodes are introduced in V8 for prototyping, and performance
measurements that are not officially a part of the current SIMD proposal
but may be included in future, gate these by a separate flag.
Change-Id: Icc6a9e89c6196c8ff144d2e0193d707e1f60c38b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079539
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66542}
Implements AtomicWait on 64-bit platforms. Note that this implementation
does not use {PrepareCall}, as planned originally. This will be done in
a separate CL, to prepare the implementation for 32-bit platforms. This
CL for now unblocks the implementation on x64.
R=clemensb@chromium.org
Bug: v8:10108
Change-Id: I52eb752364b231043975f62913c2ef9579321038
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074400
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66537}
Stack parameters in the StubCallDescriptor were set to the wrong type. I
changed it now so that for stack parameters that are specified in the
CallInterfaceDescriptor, type specified type is used. All other
parameters are assumed to be tagged, as it has been until now.
Original change's description:
> [wasm] Refactor AtomicWait implementation
>
> The existing implementation included aspects that are not
> straight-forward to implement in Liftoff and seemed inefficient:
> * Convert the timeout in WebAssembly code from I64 to F64, just to
> convert it back in the runtime.
> * On 32-bit platforms this conversion needs an additional C-call.
> * Split the I64 expected value from I64 into two I32 values in the
> wasm-compiler.
> * Ideally the int64-lowering takes care of 32-bit specific handling.
>
> With this CL the timeout and the expected value are passed as I64 to
> the runtime (a builtin moves the I64 into a bigint for that). The
> int64-lowering takes care of 32-bit platforms. There are special
> builtins for 32-bit platforms, but they are written such that ideally
> also the int64-lowering could create them.
Bug: v8:10108
Change-Id: Ib87b543666708457c0d686208a86e46cdca3f9a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080362
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66533}
This reverts commit 77d4e23047.
Reason for revert: verify csa build bot broken
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/16218?
Original change's description:
> [wasm] Refactor AtomicWait implementation
>
> The existing implementation included aspects that are not
> straight-forward to implement in Liftoff and seemed inefficient:
> * Convert the timeout in WebAssembly code from I64 to F64, just to
> convert it back in the runtime.
> * On 32-bit platforms this conversion needs an additional C-call.
> * Split the I64 expected value from I64 into two I32 values in the
> wasm-compiler.
> * Ideally the int64-lowering takes care of 32-bit specific handling.
>
> With this CL the timeout and the expected value are passed as I64 to
> the runtime (a builtin moves the I64 into a bigint for that). The
> int64-lowering takes care of 32-bit platforms. There are special
> builtins for 32-bit platforms, but they are written such that ideally
> also the int64-lowering could create them.
>
> R=jkummerow@chromium.org, binji@chromium.org
>
> Bug: v8:10108
> Change-Id: I2dbba5839779961b1c5bde4c23fc3f38f1895a52
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071867
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66497}
TBR=binji@chromium.org,jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org
Change-Id: If284aa07eedddd2fbea4df8c53c7d371cac1d42e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10108
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080250
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66498}
The existing implementation included aspects that are not
straight-forward to implement in Liftoff and seemed inefficient:
* Convert the timeout in WebAssembly code from I64 to F64, just to
convert it back in the runtime.
* On 32-bit platforms this conversion needs an additional C-call.
* Split the I64 expected value from I64 into two I32 values in the
wasm-compiler.
* Ideally the int64-lowering takes care of 32-bit specific handling.
With this CL the timeout and the expected value are passed as I64 to
the runtime (a builtin moves the I64 into a bigint for that). The
int64-lowering takes care of 32-bit platforms. There are special
builtins for 32-bit platforms, but they are written such that ideally
also the int64-lowering could create them.
R=jkummerow@chromium.org, binji@chromium.org
Bug: v8:10108
Change-Id: I2dbba5839779961b1c5bde4c23fc3f38f1895a52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071867
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66497}
There were a few places that still checked against the limit for
initial memory size rather than the limit for memory size after
growth (which was recently separated from the former).
Bug: v8:7881
Change-Id: Id17d86e2f7a5dfa4f1dd35153b0cefc01f72ed33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078574
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66496}
The set of isolates known to a native module and the set of native
modules known to an isolate were not updated on cache hit. This caused
the wasm engine to collect code when it was still live in some isolate.
R=clemensb@chromium.org
Bug: chromium:1055131
Change-Id: I56682509b284c9c0dce7c95ee20ec3929e2e8c9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078583
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66488}
Most function signatures are created once and never changed. Hence pass
them as const pointer. This makes it clear in function signatures that
these parameters will not be modified.
This also avoids a few ugly const_casts where we were passing pointers
to constexpr FunctionSigs via non-const pointers.
R=jkummerow@chromium.org
Bug: v8:10155
Change-Id: Ieb658ab5582bff276f76babdaf7ddb8f72bd4790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072739
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66478}
This allows Torque code to refer to these bitfields (not currently
relevant for any of these classes), and allows the postmortem debugging
API to provide details about these bitfields.
Change-Id: I79c74a3c5ef1f77e839720a4e8ee1f8482a576ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049870
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66471}
This is a reland of 0dc598df0c
Original change's description:
> [wasm] Refactor callback triggering
>
> 1) Instead of passing three boolean values to |TriggerCallbacks|, pass
> one EnumSet which contains all events to trigger.
> 2) Remember which events already happened, to avoid triggering them
> again.
> 3) Compute triggered events once after the loop in |OnFinishedUnits|,
> instead of checking for every finished unit.
> 4) When a new callback is registered, trigger all previous events
> immediately. This solves issue v8:10217.
> 5) Replace |NotifyTopTierReady| by |AddCallback| which is identical now.
> 6) Do not call |OnFinishedJSToWasmWrapperUnits| if no wrappers were
> compiled (this is a minor performance optimization; we save taking
> and releasing a lock).
> 7) Drive-by: Make the |EnumSet| constructor really constexpr (by making
> |Mask| constexpr).
>
> R=ahaas@chromium.org
>
> Bug: v8:10217
> Change-Id: Ib3688a1687ad7b523e90efd73f4073e9f1193016
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072737
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66459}
Bug: v8:10217
Change-Id: I9f7ca424fa7f1d0379dabe230bebf62522dfc857
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074501
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66468}
This is a first step to make {WasmCode} objects smaller. Many code
offsets are currently stored in {size_t} even though there were
originally (during assembly) an int. Others are stored in {uint32_t}.
This CL switches the function index and all code lengths and offsets to
int, because
a) bigger code is not supported anyway, and
b) the style guide recommends int over unsigned types.
This makes the {WasmCode} 24 bytes smaller on x64 (from 144 to 120
bytes).
R=ahaas@chromium.org
Bug: v8:10254
Change-Id: I8f78bf4be64d59cf9393e3b6662d9d3bd153d387
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074217
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66462}
This reverts commit 0dc598df0c.
Reason for revert: Fails the wasm-cache-test blink test.
Original change's description:
> [wasm] Refactor callback triggering
>
> 1) Instead of passing three boolean values to |TriggerCallbacks|, pass
> one EnumSet which contains all events to trigger.
> 2) Remember which events already happened, to avoid triggering them
> again.
> 3) Compute triggered events once after the loop in |OnFinishedUnits|,
> instead of checking for every finished unit.
> 4) When a new callback is registered, trigger all previous events
> immediately. This solves issue v8:10217.
> 5) Replace |NotifyTopTierReady| by |AddCallback| which is identical now.
> 6) Do not call |OnFinishedJSToWasmWrapperUnits| if no wrappers were
> compiled (this is a minor performance optimization; we save taking
> and releasing a lock).
> 7) Drive-by: Make the |EnumSet| constructor really constexpr (by making
> |Mask| constexpr).
>
> R=ahaas@chromium.org
>
> Bug: v8:10217
> Change-Id: Ib3688a1687ad7b523e90efd73f4073e9f1193016
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072737
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66459}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I564b053e898db5f7b51cefa4626c0625a225c89a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10217
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074638
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66461}
1) Instead of passing three boolean values to |TriggerCallbacks|, pass
one EnumSet which contains all events to trigger.
2) Remember which events already happened, to avoid triggering them
again.
3) Compute triggered events once after the loop in |OnFinishedUnits|,
instead of checking for every finished unit.
4) When a new callback is registered, trigger all previous events
immediately. This solves issue v8:10217.
5) Replace |NotifyTopTierReady| by |AddCallback| which is identical now.
6) Do not call |OnFinishedJSToWasmWrapperUnits| if no wrappers were
compiled (this is a minor performance optimization; we save taking
and releasing a lock).
7) Drive-by: Make the |EnumSet| constructor really constexpr (by making
|Mask| constexpr).
R=ahaas@chromium.org
Bug: v8:10217
Change-Id: Ib3688a1687ad7b523e90efd73f4073e9f1193016
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072737
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66459}
1) Merge |AddBaselineCompilationUnits| into
|InitializeRecompilationProgress|.
2) Rename |InitializeRecompilationProgress| to
|InitializeRecompilation|.
3) Unify the update of |ReachedRecompilationTierField| in
|compilation_progress_|.
R=ahaas@chromium.orgCC=duongn@microsoft.com
Bug: v8:9654
Change-Id: I58324b553bf226cacb355e387c235841fdea82d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071863
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66454}
In {InitializeRecompilationProgress}, we already have logic in place to
call the callback (all callbacks really) if no compilation units were
added.
In that case, the callback in fact does not need to be added to the list
of callbacks. Instead, it's enough to just call this one callback and
then discard it.
R=ahaas@chromium.org
Bug: v8:9654
Change-Id: I60bab2d67d67d10964404d897d13ffd628ff9964
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071861
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66450}
Added a type field to elements to distinguish anyref, funcref and
nullref elements and do a proper type checking at compile time as
the spec requires.
R=ahaas@chromium.org
Change-Id: I31be7aa1170439859ca7ec5e20aabb2720c290b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069330
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66448}
Move load splat and load extend ops into the list of SIMD memory
opcodes, since they similarly take an i32 and an memarg. This fixes the
OpcodeLength calculation in function-body-decoder-impl.h.
And in turn, fixes the mjsunit test code that the fuzzer generates. See
the regress-1055692.js file for the weird S8x16LoadSplat followed by 2
kExprUnreachable, where the kExprUnreachable really is a memarg
{0x0, 0x0}. This bug was caught by the fuzzer, and that was the
generated test (with small fixes to add kExprDrop), so leaving it as it
is.
Bug: chromium:1055692
Change-Id: I743b6beb82350b5fea22c8dd10b546a02741cfed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071401
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66439}
We want to be consistent with wasdk/wasmparser.
The names used in V8 should follow the WAT convention and always start
with a dollar, both for names from the "names" section as well as
generated names.
Bug: v8:10242
Change-Id: If4dbd4c38208c9dd9377dd2f79120635a531d881
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070637
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66434}
This is a reland of 03d5a7ba9b
Nothing changed here compared to the original test. The tests on the
blink side were invalid, I fixed them in https://crrev.com/c/2066907.
Original change's description:
> [wasm] The name of a custom section can cause a validation error
>
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
>
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
>
> R=clemensb@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}
Bug: v8:10126
Change-Id: I48aaed8eb9899da1703030fb6809fe46a6e66191
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069325
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66431}
This is a reland of 548fda4afb
regress-1054466 is modified to not use 64x2 operations, since that was
causing problems on noavx/nosse builds, which requires scalar lowering,
and scalar lowering for 64x2 ops is not implemented.
Original change's description:
> [liftoff] Check fp_pair when looking up register for reuse
>
> Given two registers that are both not gp_pair, one could be an fp_pair,
> and the other not, and we will incorrect call == on them. The current
> check needs to be expanded to check that both registers are fp_pair.
>
> Bug: chromium:1054466
> Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66402}
Bug: chromium:1054466
Change-Id: If88f1ff2fb17aaa3727758cda5b368be1c6d9bd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071396
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66423}
This reverts commit 827107a7dc.
Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1054664
Original change's description:
> [wasm-debug] Let wasm scripts report correct column information.
>
> In the debugger, wasm scripts currently do not contain meaningful column
> informations. Fix that by keeping track of the offset and size of the
> wasm code section inthe module and reporting that to the debugger.
>
> Bug: chromium:1042636
> Change-Id: Ie2b5d3a50952a467d256f815c16e459cb0ae600e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011083
> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65913}
Bug: chromium:1042636
Change-Id: Ic59d71111c3274688828bdbf6894f7f3274dc50a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066983
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66409}
This extends the debug side table to also store register locations in
addition to constants and stack values.
Previously, every value that was not constant was assumed to be spilled
to the stack. This made sense, because without breakpoints we would only
emit debug side table entries at call sites, where all registers are
spilled.
With breakpoints, this changes. At break locations, values might be live
in registers.
The logic to decide whether a value will live in the register or on the
stack is extended, because we sometimes generate the debug side table
entry at a point where the registers are not spilled yet. The debug side
table entry creation needs to account for that, and assume that these
registers will still be spilled.
R=thibaudm@chromium.org
Bug: v8:10147, v8:10222
Change-Id: I3b020dfaa29fc007047663706ee286180a996bfd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066960
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66407}
This reverts commit 548fda4afb.
Reason for revert: Segfault on nosse bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/35905?
Original change's description:
> [liftoff] Check fp_pair when looking up register for reuse
>
> Given two registers that are both not gp_pair, one could be an fp_pair,
> and the other not, and we will incorrect call == on them. The current
> check needs to be expanded to check that both registers are fp_pair.
>
> Bug: chromium:1054466
> Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66402}
TBR=clemensb@chromium.org,zhin@chromium.org
Change-Id: I56f13406ef3cc3793c9d0e2273c4dc5fb0e3de38
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1054466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069327
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66405}
Given two registers that are both not gp_pair, one could be an fp_pair,
and the other not, and we will incorrect call == on them. The current
check needs to be expanded to check that both registers are fp_pair.
Bug: chromium:1054466
Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66402}
Make sure the "initial pages" memory limit is enforced correctly and
throws a CompileError when exceeded.
Bump the "maximum pages" memory limit to 65536.
The --wasm-max-mem-pages flag now controls the "initial pages" limit;
the "maximum pages" limit is always 65536 as spec'ed.
This CL depends on https://github.com/WebAssembly/spec/pull/1121.
Bug: v8:7881, v8:8633
Change-Id: I68d07cef56633b8b8ce3b3d047c14e1096daf547
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035876
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66400}
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}
This is the first piece of the wasm debugging prototype (besides the changes to
add/remove breakpoints in WasmModuleObject made with
e699f39cae).
This changelist adds the infrastructure for a GDB-remote stub that will be used
to manage debugging sessions via the gdb-remote protocol.
It enables the creation and termination of debugging sessions over TCP
connections that are managed in a separate thread.
The logic to actually send, receive and decode GDB-remote packets will be part
of a future changelist.
Build with: v8_enable_wasm_gdb_remote_debugging = true
Run with:
--wasm-gdb-remote Enables Wasm debugging with LLDB
(default: false)
--wasm-gdb-remote-port TCP port to be used for debugging
(default: 8765)
--wasm-pause-waiting-for-debugger Pauses the execution of Wasm code waiting
for a debugger (default: false)
--trace-wasm-gdb-remote Enables tracing of Gdb-remote packets
(default: false)
Note that most of this code is "borrowed" from the code of the Chromium NaCL
GDB-remote stub (located in Chromium in src\native_client\src\trusted\debug_stub).
Implementation details:
- class GdbServer acts as a singleton manager for the gdb-remote stub. It is
instantiated as soon as the first Wasm module is loaded in the Wasm engine.
- class GdbServerThread spawns the worker thread for the TCP connection.
- class Transport manages the socket connection, in a portable way.
- class Session represents a remote debugging session.
- class Target represents a debugging target and it’s the place where the
debugging packets will be processed and will implement the logic to debug
a Wasm engine.
Bug: chromium:1010467
Change-Id: Ib2324e5901f5ae1d855b96b99ef0995d407322b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1923407
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66379}
This refactors the debug side table such that we can easily add
register information later.
In particular
- vectors for types and stack offsets are combined into one;
- constants are stored in the same vector;
- locals and operand stack values are stored in the same vector.
A follow-up CL will extend the DebugSideTable to also encode locals
or operand stack values held in registers.
R=thibaudm@chromium.org
Bug: v8:10147, v8:10222
Change-Id: I97adb56b31afdb22896530c7ba2e8a24b5d31da9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062405
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66374}
Different loggers had different logic to handle unnamed wasm functions.
This CL makes sure that we always set a reasonable name when logging
wasm code, and removes handling for unnamed code in individual loggers.
Since logging only happens on user action, the code is not optimized for
performance (i.e. we always just write to a {std::string}, even if the
length of the string is known to be limited).
R=jkummerow@chromium.org
Bug: chromium:863205
Change-Id: I941f7e8050c97dc938afd7883aaeb3b6347b762d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064977
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66370}
If multiple code spaces are created, each of them currently gets its own
jump table (on 64 bit platforms). Since we try to allocate new code
spaces right after existing ones, this is often not necessary. We could
instead reuse the existing jump table(s).
This saves code space for the unneeded jump tables and avoid the cost of
patching the redundant jump tables when we replace code objects.
This CL implements this by checking whether an existing jump table (or
pair of far jump table and (near) jump table) fully covers a new code
space, and reuses the existing jump table in that case.
R=ahaas@chromium.org
Change-Id: Id8751b9c4036cf8f85f9baa2b0be8b2cfb5716ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043846
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66364}
This reverts commit 03d5a7ba9b.
Reason for revert: Needs rebaseline:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3243
Original change's description:
> [wasm] The name of a custom section can cause a validation error
>
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
>
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
>
> R=clemensb@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I5a7ea265ce47b9e685a5056bb83db6dc58f774a9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10126
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2065168
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66356}
After compiling a function with a different set of breakpoints, update
return addresses on the stack so that execution resumes in the new
code.
This allows new breakpoints to take effect immediately, which is the
expected behavior and a prerequisite for stepping.
R=clemensb@chromium.org
Bug: v8:10147
Change-Id: I67eb3b4ce23a1f3b0519935447f8b847ec888ead
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064218
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66351}
To fully support debugging in Liftoff, we need to OSR active frames by
updating their return address. Introducing source positions after
each call will help us find the correct return address in the new code.
R=clemensb@chromium.org
Bug: v8:10147
Change-Id: I0a97fa86929c471abb4cd1ed75ac6724fc385944
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064216
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66350}
The WebAssembly spec defines that the name of a custom section can cause
a validation error. The streaming decoder, however, used a separate
Decoder object to decode the name, and thereby avoided a validation
error. With this CL the streaming decoder uses the main decoder to
decode the name of the custom section.
In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
This test defined an invalid WebAssembly module and expected it to
compile. As it is a regression test, it makes no sense to fix the test.
The module is invalid because it defines the length of the custom section
to be '0', so there are no bytes in the custom section for its name.
R=clemensb@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10126
Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66348}
Port 59e9689https://crrev.com/c/2036739
Change-Id: Ie90aa9afffe36938a97b06947db136dda7e2b840
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063194
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66328}
This is the same as codegen used in TurboFan, with the registers being
referred to in a different way.
Bug: v8:9909
Change-Id: I082caabc49d6adb367b103a77e44a4e6e1be0ac1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060265
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66324}
Store a flag per isolate whether new modules should be kept in
tiered-down state from the beginning. Adjust initial compilation if flag
is set.
Bug: v8:9654
Change-Id: I5aae435fb807f3eaa7efafe9af60451ad3c7e14d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028452
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66321}
Implement the latest spec changes:
- Allow declarative segments to behave like passive & dropped segments.
- Enforce that only declared functions may be returned or used in globals
as funcref.
- Ensure that table fill does not modify any entries if OOB.
Spec tests for select and br_table are still failing due to proposal issue
Bug: v8:10156
R=ahaas@chromium.org
Change-Id: I5b95be36a67bc7482a84b848908cc4cbdf94af03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027458
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66297}
This is to fix the hang (rarely happen). The potential root cause is
that before initialing recompilation, the recompilation callback is
added and then already cleared out by other running threads from initial
compilation.
Bug: v8:10086, v8:9654
Change-Id: I769bac621cce4611ccde1f0998b0f2bc0e9c04cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2053248
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66295}
The previous code was relying on {compilation_unit_builder_} to check if
a section was after or before the code section. This only works for the
first section after code section, since the compilation unit builder is
then reset. Use an additional field to track this instead.
R=clemensb@chromium.org
Bug: chromium:1051912
Change-Id: Id1dfa803ecde2cf77f206ea781c007fc61168942
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054099
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66265}
LoadTransform cannot efficiently be executed on BE machines as a
single operation since loaded bytes need to be reversed to
match BE ordering before any operations can take place.
This CL divides LoadTransform into separate "load" and "operation"
nodes on BE machines.
Change-Id: Idc3f66d7f17647c189c75593e8906f8645448006
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050811
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66264}
Clean-up a couple of CAS loops to avoid loading after a compare_exchange
(which updates the old value), and to loosen the memory ordering to
acquire-release to avoid unnecessary fences.
Change-Id: Ifb8e5e5136f687ca5a71417a5d131a7023add054
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050390
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66235}
Each assembler has it's own way to place breakpoints:
- stop() for arm, mips*, ppc* and s390.
- debug() for arm64.
- int3() for ia32 and x64.
We can mandate a macro-assembler `DebugBreak()` method that all should
implement so one can place a breakpoint in a portable way using a
macro-assembler. This way also assemblers are in line with TurboFan, CSA, Torque
and Liftoff which all have a DebugBreak() facility.
Change-Id: Ic4332bd19ca4db53e01441d54af6632c2c1189f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020954
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#66198}
This is a reland of 410ca4c50e
Skip new test for unsupported liftoff architecture.
Previously, if there is some unsupported liftoff functions, it fall
through Turbofan but recompilation didn't catch and count it. This CL
fixes it by using requested_tier on finished units.
Avoid to tier down asm.js.
Introduce reached recompilation tier to monitor recompilation progress.
Original change's description:
> [wasm] Tierdown wasm module upon "Debugger.enable"
>
> Put a logic in Wasm Engine to tier down all existing modules per isolate
> when debugger is enabled. This CL does not handle new module added after
> debugger is enabled yet.
>
> Bug: v8:9654
> Change-Id: I87060f5c416506543fcaf231bff9999d06ba4c0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013692
> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66017}
TBR=szuend@chromium.org,bmeurer@chromium.org
Bug: v8:9654
Change-Id: I6014ae52d1e04726e64ee9267c5ce559090414d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031744
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66164}
And fix a few issues that were already found.
R=clemensb@chromium.org
Change-Id: Ib93626751220dcdd2b9647a6e352bd86bd0ef1ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039053
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66155}
