There currently is no way to enforce explicit bounds checks if the
embedder installed the signal handler for wasm trap handling (queried
via {trap_handler::IsTrapHandlerEnabled()}).
This CL adds a respective flag and makes all compilation emit explicit
bounds checks if it is disabled.
R=ahaas@chromium.org
Bug: v8:11926
Change-Id: Ie19faab1766d3105f3c22cb4470c0f15398f1d09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2989129
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75453}
The opcodes were renamed long ago, but the macros were still using the
old syntax.
This CL was created using the following command (for WASM_GET_LOCAL,
WASM_SET_LOCAL, and WASM_TEE_LOCAL):
ag -l WASM_GET_LOCAL | xargs -L 1 sed -i 's/\bWASM_SET_LOCAL\b/WASM_LOCAL_SET/g'
R=ahaas@chromium.org
Bug: v8:11074
Change-Id: I0018bea185030be29344e66e59706fed183cc2f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595446
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71835}
The interpreter is not an execution tier in production any more. It's
only used in tests.
Thus, remove {ExecutionTier::kInterpreter} and instead add a
{TestExecutionTier} that still has {kInterpreter}.
If needed (in {TestingModuleBuilder::execution_tier()}), we translate
back from {TestExecutionTier} to {ExecutionTier} (for {kLiftoff} and
{kTurboFan} only).
The {TraceMemoryOperation} method, which is shared between interpreter
and production code, now receives a {base::Optional<ExecutionTier>}, and
we will just pass en empty optional if called from the interpreter.
R=thibaudm@chromium.org
Bug: v8:10389
Change-Id: Ibe133b91e8dca6d6edbfaee5ffa0d7fe72ed6d64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335186
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69260}
This CL implements all variants of CompareExchange on arm.
Implementing 64-bit CompareExchange on arm requires a lot of registers,
with the additional constraint that the low-word register of new_value
and result have to have an even register code, and that the corresponding
high-word registers have a register code that is by one higher than the
register code of the low-word register.
This register allocation is achieved by assigning fixed registers to
all values.
R=clemensb@chromium.org, v8-arm-ports@googlegroups.com
Bug: v8:10108
Change-Id: I2edfde15e80db0d45621a461793018d88e997431
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172791
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67592}
The existing implementation needed uses of the outputs of an
AtomicExchange to allocate registers for the result value. However,
these uses are not guaranteed to exist. With this CL temp registers
get allocated if the uses don't exist.
R=gdeepti@chromium.org
Bug: chromium:1077130
Change-Id: I058ee53b87c6e995c9f490f3aebbfdba69934f3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2179503
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67556}
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 instruction selector assumed for Word32AtomicPairCompareExchange
nodes that if there exists a Projection(1) user, then there also exists
a Projection(0) user. This, however, is not the case, because TurboFan
eliminates unreachable nodes. The missing projection node lead to a
failed DCHECK in the register allocator.
With this CL we allocate the right registers for the existing
projections, and allocate the other needed registers as temp registers.
R=gdeepti@chromium.org
Bug: v8:10140
Change-Id: Id50768c3cb712db5e0eb3b9dcd0a8a479e20953a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030731
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66122}
The instruction selector assumed for Word32AtomicPairBinop nodes that if
there exists a Projection(1) user, then there also exists a
Projection(0) user. This, however, is not the case, because TurboFan
eliminates unreachable nodes. The missing projection node lead to a
failed DCHECK in the register allocator.
With this CL we allocate the right registers for the existing
projections, and allocate the other needed registers as temp registers.
R=gdeepti@chromium.org
Bug: v8:10140
Change-Id: I22331cae58f933e89dac6993fe3b21ff6502838a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011829
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65941}
The instruction selector assumed for Word32AtomicPairLoad node that if
there exists a Projection(1) user, then there also exists a
Projection(0) user. This, however, is not the case, because TurboFan
eliminates unreachable nodes. The missing projection node lead to a
failed DCHECK in the register allocator.
To fix the problem I use now the Word32AtomicPairLoad node directly to
allocate the register. On ia32 I stop additionally to allocate unneeded
temp registers.
R=gdeepti@chromium.orgCC=zhin@chromium.org
Bug: chromium:1042379
Change-Id: I79bd9f3f4672e147246a71c32b7c9b4dbd79b17f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002547
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65912}
This CL changes the usage pattern from
FOR_XXX_VALUES(i) { Use(*i); }
to
FOR_XXX_VALUES(i) { Use(i); }
which is way more intuitive.
Note that the replacement in the uses was done via regular expression,
so it's purely mechanical. In two locations I removed unneeded braces
around the macro, because they confused clang-format.
I plan to do more cleanups (remove redundant assignments within the
FOR_XXX_VALUES body) in a follow-up CL.
R=mstarzinger@chromium.org
Bug: v8:8562
Change-Id: I4329bfcf34e5b077d19b50f4204ceb3b4340fe61
Reviewed-on: https://chromium-review.googlesource.com/c/1449615
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59287}
Clusterfuzz generated test cases for narrow Load, CmpExchg nodes in
which the index is a word64 expression. This was not handled correctly
leading to a malformed graph. Use default lowering for all atomic
narrow operations, and add reduced test cases in wasm cctests with the
same sequence as the ones generated by binaryen for other I64Atomic
operations as well.
Change-Id: I50d63747b16a8f69289ca4e76547b325d84b22d3
Bug: chromium:921366, chromium:920120, chromium:900681
Reviewed-on: https://chromium-review.googlesource.com/c/1423177
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59012}
Handle the case when one or both of the output nodes of an I64Atomic op
are optimized, for code-gen instructions that use a set of fixed
registers, use temp registers to ensure the registers are not
clobbered.
BUG:v8:6532
Change-Id: I52763c48d615cdf3ae8d754402b11da2df31a4a1
Reviewed-on: https://chromium-review.googlesource.com/1195910
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56004}
The AtomicNarrow operations are currently used for wider 64-bit
operations, that only operate on 32-bits of data or less
(Ex:I64AtomicAdd8U). Removing these because this can be handled
in int64-lowering by zeroing the higher order node.
Explicitly zeroing these in code-gen is not
required because -
- The spec requires only the data exchange to be atomic, for narrow
ops this uses only the low word.
- The return values are not in memory, so are not visible to other
workers/threads
BUG:v8:6532
Change-Id: I90a795ab6c21c70cb096f59a137de653c9c6a178
Reviewed-on: https://chromium-review.googlesource.com/1194428
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55499}
Linkage-related methods were declared in wasm-compiler.h and
implemented in wasm-linkage.cc. This required all users of e.g. wasm
call descriptors to include the whole wasm compiler header. Also, some
wasm linkage information is independent of turbofan and also used
outside of the compiler directory.
This CL splits off wasm-linkage.h (with minimal includes) and puts it
in src/wasm. This allows to use that information without including
compiler headers (will clean up several uses in follow-up CLs).
R=mstarzinger@chromium.org, titzer@chromium.org
Bug: v8:7570
Change-Id: Ifcae70b4ea7932cda30953b325c2b87c4176c598
Reviewed-on: https://chromium-review.googlesource.com/1013701
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52849}
First version which can compile a very basic code.
Change-Id: I3b98412a5ca39a28f8fe5b60516b82c6981dd187
Reviewed-on: https://chromium-review.googlesource.com/993232
Commit-Queue: Vincent Belliard <vincent.belliard@arm.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52622}