When the input to F64x2PromoteLowF32x4 is a S128Load64Zero, we can skip
the load + promote, and promote directly with a memory operand. The
tricky bit here is that on systems that rely on OOB trap handling, the
load is not eliminatable, so we always visit the S128Load64Zero, even
though after instruction-selector pattern-matching, it is unused. We
mark it as defined to skip visiting it, only if we matched it.
Bug: v8:12189
Change-Id: I0a805a3fce65c56ec52082b3625e1712ea1ee7cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3154347
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76917}
When checking for operand interference, if both operands are slots and
one of them is 128 bit wide, check that the slot ranges don't intersect.
R=nicohartmann@chromium.org
Bug: chromium:1248817
Change-Id: Ib18b6e596dbb23427508b7cc07947a0ab4665e85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162141
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76904}
This reverts commit 16df1dfa13.
Reason for revert: Multiple failures, e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/43844/overview
Original change's description:
> [arm64][wasm-simd] Use Cm(0) for integer comparison with 0
>
> Use an immediate zero operand for integer comparison when possible. This
> gives ~1% runtime performance improvement in some benchmarks on Neoverse
> N1.
>
> Change-Id: I727a8104f8e6ca3d122d6b5b8b3d38d7bdd76c47
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3158327
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
> Cr-Commit-Position: refs/heads/main@{#76847}
Tbr: zhin@chromium.org
Change-Id: I7039106d885c59aecad24dd8dda4d151b8e1f022
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162053
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76851}
Use an immediate zero operand for integer comparison when possible. This
gives ~1% runtime performance improvement in some benchmarks on Neoverse
N1.
Change-Id: I727a8104f8e6ca3d122d6b5b8b3d38d7bdd76c47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3158327
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/main@{#76847}
By delegating to the macro-assembler, emit AVX instructions for some
float opcodes (float sqrt, round, conversions to and from int,
extract/insert/load word).
Since they now support AVX, we rename the instruction ops to remove the
SSE prefix, changing it to be IA32.
Bug: v8:12148
Change-Id: Ib488f03928756e7d85ab78e6cb28eb869e0641f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3131374
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76755}
Use an immediate zero operand for floating point comparison nodes when
possible. This results in up to 20-25% runtime improvement in some
microbenchmarks, as well as 1-1.5% runtime improvement in some
real-use benchmarks on Cortex-A55 and Neoverse N1.
Change-Id: I39d10871a08a037dbe8c0877d789d110476e1a58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3133143
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/main@{#76749}
This is a reland of 65515ddd3e
Fix is to use AddWithWraparound for signed additions to avoid UB.
Original change's description:
> [wasm-simd][arm64] Fuse add and extmul
>
> We can select a better instruction for add+extmul, using one of the
> multiply-long-accumulate instruction.
>
> Define a helper struct to pattern match Add(x, OP(y, z)) and
> Add(OP(x, y) z), and ensure that the matched OP is always on the
> LHS, to simplify checking for matches.
>
> Bug: v8:11548
> Change-Id: I7ab488b262aa9f749785f973549ccd9fad72f4c8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826725
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76708}
Bug: v8:11548
Change-Id: I675ab8b78d9c6c30b82a8c96c8e7098a548c6a60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3144379
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76712}
This reverts commit 65515ddd3e.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/18117/overview
Original change's description:
> [wasm-simd][arm64] Fuse add and extmul
>
> We can select a better instruction for add+extmul, using one of the
> multiply-long-accumulate instruction.
>
> Define a helper struct to pattern match Add(x, OP(y, z)) and
> Add(OP(x, y) z), and ensure that the matched OP is always on the
> LHS, to simplify checking for matches.
>
> Bug: v8:11548
> Change-Id: I7ab488b262aa9f749785f973549ccd9fad72f4c8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826725
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76708}
Bug: v8:11548
Change-Id: Ic1560616e7ee6df917fcedbb6ad139a1a9773d68
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3144377
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#76709}
We can select a better instruction for add+extmul, using one of the
multiply-long-accumulate instruction.
Define a helper struct to pattern match Add(x, OP(y, z)) and
Add(OP(x, y) z), and ensure that the matched OP is always on the
LHS, to simplify checking for matches.
Bug: v8:11548
Change-Id: I7ab488b262aa9f749785f973549ccd9fad72f4c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826725
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76708}
Handle all 4 selects that wasm-compiler generates.
Also modify unittest to allow optional operations (select
operations are not supported on all archs).
Bug: v8:12136
Change-Id: Ia54d7a71cffaa1c5cc8203520a1f3d812997bbb1
Fixed: v8:12136
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3119991
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76539}
1. Move Abspd, Negpd from MacroAssembler into TurboAssembler so that we
can use it in code-generator
2. Add Absps and Negps (float32 versions of the instructions in 1)
3. Refactor SSE/AVX float32/float64 abs/neg to use these macro-assembler
helpers.
4. Use these helpers in Liftoff too
This has the benefit of not requiring to set up the masks in a temporary
register, and loading the constants via an ExternalReference instead.
It does require (in ins-sel) to have the input be in a Register, since
the ExternalReference is an operand (and the instruction can only have 1
operand input).
Bug: v8:11589
Change-Id: I68fafaf31b19ab05ee391aa3d54c45d547a85b34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3123635
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76520}
This removes 4 arch opcodes.
Bug: v8:11217
Change-Id: Idff04fb205c7d7d1577ce123cc2160d678dfe39a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114599
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76473}
This removes 8 arch opcodes.
Bug: v8:11217
Change-Id: I2c7a73b032ba5fa21f9843ebb4325e226a22550a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114590
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76442}
We are running out of encoding space for opcodes on arm64. This patch
merges some wasm simd opcodes of different simd types, encoding the lane
size in the instruction code using LaneSizeField instead. This reduces
the total number of opcodes on arm64 by 71.
Bug: v8:12093
Change-Id: Ib4d96d1db1ff9b08fafd665974f3494a507da770
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3109676
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/main@{#76434}
This is a reland of 2261e05333
This patch can now be relanded as some space was made for more opcodes:
https://bugs.chromium.org/p/v8/issues/detail?id=12093
Original change's description:
> [arm64][wasm] Use NEON S/Usra for Wasm SIMD add(shr(x, imm), y)
>
> A single AArch64 SIMD signed/unsigned Shift Right and Accumulate can be
> used to implement Wasm SIMD add(shr(x, imm), y). This gives a 1-1.5%
> improvement on some compute intensive Wasm benchmarks on Neoverse-N1.
>
> Mla and Adalp optimisations were refactored to match the style of the
> added code.
>
> Change-Id: Id5959a31ca267e02b7d60e7ff6f942adb029b41e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089157
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
> Cr-Commit-Position: refs/heads/master@{#76280}
Change-Id: Idd166b7d3c960af33049bbce6e7276763c28f286
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097284
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76340}
Bug: v8:12008
Change-Id: I2e1d918a1370dae1e15919fbf02d69cbe48f63bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089095
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76308}
This is identical to https://crrev.com/c/3094011, but for 16-bit values.
We introduce another instruction to differentiate between 16->32 bit
sign extensions and 16->64 bit sign extensions.
R=ahaas@chromium.org, mslekova@chromium.org
Bug: chromium:1239116
Change-Id: I2742e9d9c2b4a038fc7a0b1715faf8f25fa20b1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094012
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76284}
InstructionSelector::ZeroExtendsWord32ToWord64 assumes that a
Load[kRepWord8|kTypeInt32] generates a zero-extended value. This
assumption makes sense, but was not fulfilled by the instruction
selector which emitted an "ldrsb" instruction which sign-extended to the
full 64-bit register.
This CL fixes that by introducing a separate "LdrsbW" instruction which
is selected if we are sign-extending an 8-bit value to 32-bit.
R=ahaas@chromium.org, mslekova@chromium.orgCC=v8-arm-ports@googlegroups.com
Bug: chromium:1239116
Change-Id: I2da1ad6062805acf5558f3e66b8db9a50e830302
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094011
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76283}
This reverts commit 2261e05333.
Reason for revert: No issues with the CL, but it is taking the
last two available opcodes on arm64 (we use 9 bits to encode it,
so we are limited to 512 opcodes). We need to land a security fix
which includes the addition of two opcodes. Before relanding this,
we need to figure out a strategy to either reduce opcodes, or use
one more bit to encode them.
Original change's description:
> [arm64][wasm] Use NEON S/Usra for Wasm SIMD add(shr(x, imm), y)
>
> A single AArch64 SIMD signed/unsigned Shift Right and Accumulate can be
> used to implement Wasm SIMD add(shr(x, imm), y). This gives a 1-1.5%
> improvement on some compute intensive Wasm benchmarks on Neoverse-N1.
>
> Mla and Adalp optimisations were refactored to match the style of the
> added code.
>
> Change-Id: Id5959a31ca267e02b7d60e7ff6f942adb029b41e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089157
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
> Cr-Commit-Position: refs/heads/master@{#76280}
Change-Id: Ifad0625ed8a6b66e7a7a74da11ad7d60941207e5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094014
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#76282}
A single AArch64 SIMD signed/unsigned Shift Right and Accumulate can be
used to implement Wasm SIMD add(shr(x, imm), y). This gives a 1-1.5%
improvement on some compute intensive Wasm benchmarks on Neoverse-N1.
Mla and Adalp optimisations were refactored to match the style of the
added code.
Change-Id: Id5959a31ca267e02b7d60e7ff6f942adb029b41e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089157
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#76280}
These are no longer enabled, so remove the code mitigation logic from
the codebase.
BUG=chromium:1003890
Change-Id: I536bb1732e8463281c21da446bbba8f47ede8ebe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045704
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76256}
Bug: v8:7790
Change-Id: Ia5903364a774bd49db1a646b3066b9972deac725
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074465
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76119}
This wraps up the transition away from kSerialized ref kinds.
Since JSFunctionRef is a complex type, we don't attempt full
consistency on the background thread. Instead, we serialize functions
on the background in a partially-racy manner, in which consistency
between different JSFunction fields is *not* guaranteed. Consistency
is later verified through a new compilation dependency kind during
finalization.
Bug: v8:7790, v8:12004
Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75789}
A frame state's outer frame state input can be kDeadValue. A DCHECK
did not take that into account. In release builds there was no issue
because we branch on the opcode anyways.
While fixing this bug, I'm strengthening the FrameState class such that
a FrameState node must have a kFrameState operator. I'm also
- changing the result type of outer_frame_state() from FrameState to
Node* since it may in fact not be a kFrameState;
- removing has_outer_frame_state() because I find it unintuitive to
have outer_frame_state() return non-NULL even when
has_outer_frame_state() would return true.
Bug: chromium:1224758
Change-Id: I8ebed75c62e31f7eef71e2941fd18869d8a56af3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001356
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75553}
Grouping a couple of small, non-functional fixes:
- add a comment to GetStackParameterDelta
- small typo fixes to a couple of places I saw while reading related
code
Bug: v8:11879
Change-Id: I8566c9778fd6268b08ea3aefbdaa84ef894bcd35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2997922
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75490}
We would be allowing or disallowing using the local heap rather than
that scope. There's one case that remains in common-operator-reducer.cc.
Bug: v8:7790
Change-Id: Ice0b407aa37b3aa349fc68f4a7c2644156097e3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2983206
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75379}
This is a reland of 9701d4a420
with a small fix for some code landed in between the dry-run and
submission.
Original change's description:
> [base] Move most of src/numbers into base
>
> Moves all but conversions.*, hash-seed-inl.h and math-random.* into
> base, in preparation for moving the parts of conversions that don't
> access HeapObjects.
>
> Also moves uc16 and uc32 out of commons/globals.h into base/strings.h.
>
> Bug: v8:11917
> Change-Id: Ife359148bb0961a63833aff40d26331454b6afb6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979595
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Auto-Submit: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75354}
Bug: v8:11917
Change-Id: Ie1ec9032fe56646a7c7303185cecc70fce5694ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982607
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75368}
This reverts commit 9701d4a420.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64/40802/overview
Original change's description:
> [base] Move most of src/numbers into base
>
> Moves all but conversions.*, hash-seed-inl.h and math-random.* into
> base, in preparation for moving the parts of conversions that don't
> access HeapObjects.
>
> Also moves uc16 and uc32 out of commons/globals.h into base/strings.h.
>
> Bug: v8:11917
> Change-Id: Ife359148bb0961a63833aff40d26331454b6afb6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979595
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Auto-Submit: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75354}
Bug: v8:11917
Change-Id: Iacf796c95256016fa74f0a910c5bb1a86baa425a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982605
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75356}
Moves all but conversions.*, hash-seed-inl.h and math-random.* into
base, in preparation for moving the parts of conversions that don't
access HeapObjects.
Also moves uc16 and uc32 out of commons/globals.h into base/strings.h.
Bug: v8:11917
Change-Id: Ife359148bb0961a63833aff40d26331454b6afb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979595
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75354}
This also removes intrinsics that were just used in tests. It keeps
InlineIncBlockCounter for now because it's a less straightforward.
Change-Id: I77e55d7a746294892d0fd7ab577ebf8eb42f1f08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953195
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75217}
The two instructions are fused into a single Uadalp instruction,
improving performance of quantized neural network operator
implementations such as XNNPACK.
Bug: v8:11546
Change-Id: Ic11b35d1e7758ee0b4ccfe8f592edc1aa798f6f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2939997
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Daan de Graaf <daagra@google.com>
Cr-Commit-Position: refs/heads/master@{#75102}
- Add new Builtin enum
- Move Builtins::Name:kXXX to Builtin::kXXX
- Update existing code
Follow CLs will unify the mix of using int builtin-ids and
Builtins::Name to only use the new Builtin enum and changing it to
an enum class.
Change-Id: Ib39aa45a25696acdf147f46392901b1e051deaa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905592
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74995}
The two instructions are fused into a single Sadalp instruction,
improving performance of quantized neural network operator
implementations such as XNNPACK.
This change also includes some formatting changes to the unit
tests that were made automatically by clang-format, which I am
happy to revert if preferred.
Bug: v8:11546
Change-Id: I2afc8940a52186617cffd276c82733ad3020b728
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878742
Commit-Queue: Daan de Graaf <daagra@google.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74952}
And add s10 to scratch_register_list. Clean up t* register used in macroassembler
Bug: v8:7703
Change-Id: Ib8477cd7528b8c2a2297da3f46659f30af45286e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2914246
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Brice Dobry <brice.dobry@futurewei.com>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/master@{#74841}
As mentioned in this CL https://crrev.com/c/2510070,
PPC_OWNERS file is the only necessary file applied
to all *-ppc* files.
Change-Id: I2052186660c6d186e3ead3e8e127a9129814377f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2892602
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74536}
Loop unrolling did not work properly with floating control. Seeing as
very few spots in the wasm compiler introduced floating control, we
decided to disallow it altogether.
Changes:
- When lowering 64-bit rol/ror/clz/ctz in 32-bit platforms, we use a
diamond operator, which used to introduce floating control. This CL
adds a control edge to these operators so that the diamond can be
chained to that control instead.
- During loop analysis, as an additional safety check, we check that the
explored loop does not have floating control. Exceptionally, floating
control pointing directly do start() is allowed.
- Change wasm-compiler so that generated floating projections point to
start() even after stack check patch-in.
Bug: chromium:1184929, v8:11298
Change-Id: I1ee063f5250037ae6c84d2f16b0bd8fff3923117
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876851
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74527}
When a function is invoked by prototype.apply, it may undergo following transformation in the JSCallReducer:
receiver.apply(this, args) ->
this.receiver(...args) Since the new target (also the receiver of apply()) is not collected to the feedback slot, further speculative optimization on the new target is not available if the new target
is not a heapconstant.
With this CL, the receiver will be collected to the feedback instead of the target if the target is a prototype.apply. It may improve the performance of the following usecase by ~80%.
function reduceArray(func, arr, r) {
for (var i = 0, len = arr.length; i < len; i++) {
r = func.apply(null, r, arr[i]);
}
return r;
}
var a = 0; for (var i = 0; i < 10000000; i++) {
a += reduceArray(Math.imul, [5,6,2,3,7,6,8,3,7,9,2,5,], 1);
}
console.log(a);
This CL also improves the runTime score of JetStream2/richards-wasm by ~45% in default, ~60% with --turbo-inline-js-wasm-calls.
Change-Id: I542eb8d3fcb592f4e0993af93ba1af70e89c3982
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639813
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74413}
cpplint rules change over time, and we change the exact rules we enable
for v8. This CL removes NOLINT annotations which are not needed
according to the currently enabled rules.
R=ahaas@chromium.org
Bug: v8:11717
Change-Id: Ica92f4ddc9c351c1c63147cbcf050086ca26cc07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859854
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74297}
Modify TryAnyExtendMatch to combine Int64Add/Int64Sub(x, ChangeInt32ToInt64(y))
to use an extend register operand, removing the cast.
Change-Id: Id130f8a9614e2c208f9ed8c17b923ee738fcb916
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857964
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#74285}
This reverts commit d2ce574457.
Reason for revert: We reverted the early canonicalization change, so we need to worry about non-canonicalized shuffles now.
Original change's description:
> [wasm-simd][arm64] Update f32x4.mul(dup) pattern matching
>
> We now canonicalize earlier in the pipeline, and don't need to worry
> about non-canonicalized shuffles.
>
> Bug: v8:11542,v8:11257
> Change-Id: If9f5c44061465be339c98e479fd8c5a437bbd74b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778673
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73645}
Bug: v8:11542
Bug: v8:11257
Change-Id: Ib492b3ab7ad140193975d2641999c12c9697e27b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850630
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74193}
Instead of running a second pass of the scheduled graph after
effect control linearization to do machine lowering, integrate
the machine lowering reducers (MemoryLowering and SelectLowering)
into the graph assembler used by the effect control linearization.
This saves running through the graph and re-maintaining the schedule
for the second time, reducing overhead in Turboprop.
BUG=v8:9684
Change-Id: Ib0fed19089287c8e801a063333cb8404181411db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848474
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74178}
On a per-job basis, --turbo-direct-heap-access should be equal to
whether concurrent inlining is enabled. We simplify involved logic by
removing the flag, and replacing all access to
- FLAG_turbo_direct_heap_access, and
- FLAG_concurrent_inlining
inside compiler/ with
OptimizedCompilationInfo::is_concurrent_inlining() (or derived values).
Bug: v8:7790
Change-Id: I64818e0e1004dded08c784ef1c4bdfd2af990a59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843345
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74166}
This reverts commit d16eefe0f2.
It is not correct to check for node equality during the graph
construction phase, because we can have optimizations that will combine
same nodes. So it can happen that in wasm-compiler, the inputs to
shuffle are not the same, so we canonicalize using that knowledge that
it will not be the same, and allow indices > 15. But later we can have
optimizations that combine the 2 inputs (e.g. splat of the same
constants), and the instruction selector will see that the input nodes
are the same.
Bug: v8:11542,chromium:1199662
Change-Id: I21c175f4707708038710147f64d687d1b14c6ecc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2829986
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74017}
This is a reland of ae0752df1b
Reland fixes:
* Remove UNREACHABLE() from constexpr switch, since we don't have a
CONSTEXPR_UNREACHABLE() (it's ok, the switch is exhaustive for the
enum anyway).
* Fix IsRegisterArray trait to use public inheritance and size_t for
std::array size.
Original change's description:
> [codegen] Add static interface descriptors
>
> Add a new CRTP StaticCallInterfaceDescriptor class, which provides
> static constexpr getters for a descriptor's registers, parameter counts,
> and so on. Each CallInterfaceDescriptor subclass is changed to extend
> StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself
> extending CallInterfaceDescriptor to still provide a dynamic lookup
> where needed.
>
> StaticCallInterfaceDescriptor provides a couple of customisation points,
> where it reads its CRTP derived descriptor's static fields and
> functions, with default fallbacks where appropriate. With these
> customisation points, the definition of CallInterfaceDescriptor
> subclasses is simplified to:
>
> a) Providing parameter names (as before)
> b) Providing parameter types (as before)
> c) Optionally setting flags (like kNoContext or kAllowVarArgs) as
> static booleans on the class.
> d) Optionally providing a `registers()` method that returns a
> std::array<Register, N> of registers that may be used for
> parameters (if not provided, this defaults to the implementation
> specific default register set).
>
> Parameter registers (and register count) are automagically set based on
> the number of parameters and number of given registers, with extra magic
> to ignore no_reg registers (to reduce ia32 special casing). The
> CallInterfaceDescriptorData is initialized based on these static
> functions, rather than manual per-descriptor initializers.
>
> This allows us to skip loading descriptors dynamically for CallBuiltin
> in Sparkplug, and instead lets us use a bit of template magic to
> statically set up arguments for the calls. Any other users of statically
> known descriptors will also benefit, thanks to C++ picking the static
> methods over the dynamic methods on the base class when available.
>
> Because we can remove various virtual functions and trigger heavier
> inlining of constantly known values, binary size slightly decreases with
> this change.
>
> Note that torque-generated descriptors are changed to use the same magic,
> rather than having Torque-specific magic, for consistency.
>
> Bug: v8:11420
> Change-Id: Icc5e238b6313a08734feb564204a13226b450c22
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73996}
TBR=nicohartmann@chromium.org,clemensb@chromium.org,ishell@chromium.org,clemensb@chromium.org
Bug: v8:11420
Change-Id: Icd1f6cdb3c178e74460044b1e9623139929ceba8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831872
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74010}