In the codegen for shift operations, we update the temp s128 register
with the shift value, before shifting src with temp. Thus we really want
src to be a different register from temp.
I found this with some locally-ran fuzzing.
Bug: v8:10115
Change-Id: Ie492570c672f352f0e19aef2b8498c86ec4fdd98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2107359
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66756}
This optimizes i8x16 shifts when shift value is constant. It reduces
instruction counts from 10 to 6 (unsigned), and 9 to 5 (signed).
We can use a word (16-bit) shift, then mask away the high (shru) or low
(shl) bits to achieve a byte shift. Most of the instructions are
dedicated to building the mask.
Bug: v8:10115
Change-Id: Ie602c2b0a7227181502fadb14e100bb0b92f322f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2103445
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66755}
Delegate to macro assembler functions to pick between SSE or AVX. This
simplifies the optimization of constant shifts later.
Bug: v8:10115
Change-Id: If0b7dc83a68f2d7839c65527a3b6a62310ace6dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2103443
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66753}
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}
To avoid that constant folding makes some type assertions hold
vacuously, we don't constant-fold directly but instead introduce a new
FoldConstant operator that remembers the original node and gets lowered
to an equality assertion by the EffectControlLinearizer.
Change-Id: I7aedbe6d4fe47461856723c0c40ba3313a376bd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100992
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66746}
The macro is not needed, the same condition can also be expressed
programmatically. Its name is misleading anyway, since it has nothing to
do with the wasm64 proposal.
Drive-by: Use GraphAssembler to implement {BuildF64CopySign}.
R=jkummerow@chromium.org, tebbi@chromium.org
Bug: v8:10123, v8:10155
Change-Id: I85238172037f08bd2e4d2d4564950759524f991a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105637
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66743}
This is a reland of 2c834c5364,
in which node replacement was too aggressive.
Original change's description:
> [turbofan] Clean up ConstantFoldingReducer
>
> Change-Id: Iaf7f83cc157a6f6680da8933560347f7f3503d56
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098736
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66706}
Change-Id: I5d306092dde4119629af4c5e7e424a0e9a14310d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106193
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66742}
This reverts commit 2c834c5364.
Reason for revert: several clusterfuzz issues, e.g. 1061805
Original change's description:
> [turbofan] Clean up ConstantFoldingReducer
>
> Change-Id: Iaf7f83cc157a6f6680da8933560347f7f3503d56
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098736
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66706}
TBR=neis@chromium.org,tebbi@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I6e5b655bb465087a50ebaa2088795c6f920c2e51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2104892
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66717}
Based on feedback in https://github.com/WebAssembly/simd/issues/189 and
inspired by cranelift's codegen, we reduce instruction count by 1 for
both types of operations - all_true goes from 6 -> 5, any_true from 4 ->
3. The main transformation is to change a sequence of movq + ptest +
cmovq to ptest + setcc. We unfortunately cannot cut down the instruction
counts further, since we need to zero the destination register.
Change-Id: Idc2540dbec755c7a7ff5069955f74e978190161d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100994
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66710}
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}
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}
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}
... such that we have only a single representation for special
constants such as undefined, namely the corresponding bitset.
With this CL the following property holds:
t1.IsSingleton() /\ t2.Is(t1) => t1.Is(t2)
Also clean up the Type interface and improve test coverage a little.
Change-Id: I074e20047c92e2c8215c2d438f2627f4ffdbc409
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096631
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66684}
In typed lowering, if our target is a CheckClosure or a CreateClosure
node, we can extract a SharedFunctionInfo from the opcodes
parameters in order to make calls a bit more efficient.
Change-Id: Ib06dea2e8505bfeb984c4cefd5ad1bed0defa5f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087402
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66683}
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}
Generalize the HeapConstant case to a Singleton case.
Change-Id: Ief8c325a4326e02c8c361f3b41fc40ca398167ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096619
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66659}
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}
The arguments order in a JS stack is now controlled by
V8_REVERSE_JSARGS macro.
This CL creates two stubs that allow the order of the arguments
to be reversed without changing CallStub.
Bug: v8:10201
Change-Id: I8f70adf3ced1f45a00f5c4ddd47d5f604f2d3100
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093506
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66647}
Useful for profiling why mksnapshot is so slow in conjunction with
--runtime-call-stats.
Change-Id: Ib193d292352e0019b93c8edccb38a904aadbf553
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089932
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66646}
There exists the pattern in wasm-compiler.cc of allocating a stack slot
and filling it with values. This CL introduces a helper function for
this pattern. Note that not all cases of this pattern can be changed to
use the helper function. In these cases either the size of the stack
slot is not statically known, or the stack slot is also used for return
values.
R=clemensb@chromium.org
Bug: v8:10155
Change-Id: I8497a22fed730424561fc32bc1cfa21643341643
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093495
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66631}
Bug: v8:7790
Change-Id: Ibdfe1c1a1ad2eb082583285493227fb833be4690
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093501
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66629}
In the process:
* Augment C++-generated Torque classes with SizeFor methods to
calculate size of instances.
* Add a new "@generateBodyDescriptor" annotation that causes Torque to
generate C++ BodyDescriptors code that can be used to visit objects
compatible with existing V8 mechanisms, e.g. GC
* Fully automate C++ macro machinery so that adding non-extern Torque
class doesn't require any C++ changes, including ensuring generation
of instance types and proper boilerplate for validators and
printers.
* Make handling of @export a true annotation, allowing the modifier to
be used on class declarations.
* Add functionality such that classes with the @export annotation are
available to be used from C++. Field accessors for exported classes
are public and factory methods are generated to create instances of
the objects from C++.
* Change the Torque compiler such that Non-exported classes implicitly
have the @generateBodyDescriptor annotation added and causes both
verifiers and printers to be generated.
* Switch non-extern Torque classes from using existing Struct-based
machinery to being first-class classes that support more existing
Torque class features.
Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66621}
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}
This fixes a non-determinism issue caused by the cache being full.
Depending on the non-deterministic value of the handles in HeapConstant
nodes, different cache entries would be overwritten in this case.
The old implementation of NodeCache had a fixed limit, overwriting
entries when the cache is full. This behavior didn't really make sense,
but the hand-written hash map implementation couldn't handle arbitrary
numbers of hash collisions, so removing the limit wasn't an option either.
Thus this CL just replaces the custom hash map with a normal
std::unordered_map, that is, a ZoneUnorderedMap.
Bug: chromium:1046815
Change-Id: I95269f2b1068eb9dfe3ee2ab5cca1cb460bc8fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087405
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66592}
Optimizes InstructionSelector::AddInputsToFrameStateDescriptor by
taking advantage of SparseInputMask data structure to more quickly
handle empty inputs and insert all the OptimizedOut entries in one go.
The number of empty inputs is now determined using CountTrailingZeros
rather than iterating over them one at a time.
Gives a 9% improvement to SelectInstructions runtime call stat for
Octane in turboprop.
Bug: v8:10051
Change-Id: Ib13d6f9644b4c89ba0546a19fe0ed623d69fec99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037443
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66591}
Change-Id: I6094bc17e8a482f166bdb53e5d2dabe9a1299c9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087409
Commit-Queue: Dan Elphick <delphick@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66590}
This CL simplifies IC code since we no longer need to keep
feedback slot indices in both Smi and IntPtr form and as
a result it should improve overall performance of --no-opt
mode on Octane by ~1%.
Bug: v8:10047
Change-Id: Ib717697cdb805c9f93286e9c62ee8a63361d3560
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965586
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66585}
