This adds a few tests that test that the output of Liftoff is
deterministic.
These tests will be extended to test the debug side table in follow-up
CLs.
R=mstarzinger@chromium.org
Bug: v8:10019
Change-Id: Ia7992e7a889bf6dad963e5abe5b50507735996a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932371
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65190}
Make WasmFeatures a proper class which uses an EnumSet under the hood.
This way, it inherits all behaviour of EnumSet like comparison, merge,
etc.
Accesses change from being simple field access into the struct to
actually bit tests in the EnumSet.
R=mstarzinger@chromium.org
Bug: v8:10019
Change-Id: I768f92b90ac0294156f4482defba5ce00bc70165
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934334
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65184}
Until now, the in-object properties on JSObject have been invisible to
tools using the postmortem debugging library. With this change, those
tools will get enough information to show a flat list of property
values. This is still less powerful than the runtime printers, which can
show the corresponding key for each value, but it's a big step up from
manually inspecting memory.
This change basically requires a reimplementation of
Map::GetInObjectProperties for postmortem debugging. I'm not
enthusiastic about duplicating this logic, but it's pretty small and I
don't see any good alternatives.
As a drive-by cleanup, I moved some inline string literals into a batch
of constexpr char arrays.
Bug: v8:9376
Change-Id: Ia24c05f6e823086babaa07882d0d320ab9a225db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930174
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65183}
This flag has had no effect since mid 2017 when its use-site was
accidentally removed (in https://codereview.chromium.org/2902533003).
Change-Id: I81436b064c2664deff781ad6d75ad47937e3fdc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934333
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65172}
Properly handle termination exceptions in TLA modules.
Bug: v8:9978
Change-Id: Ica70a55d1f54ec89d175d7c846e9a405eaffe0a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1920750
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65135}
InstanceBuilder::LoadTableSegments - Throw RuntimeError instead of
LinkError
WasmGraphBuilder::TableInit & WasmGraphBuilder::MemoryInit - Do not
check for active/dropped status if size == 0
WasmGraphBuilder::MemoryFill - Throw out-of-bounds error BEFORE
attempting any memory operations if necessary
R=ahaas@chromium.org
Bug: v8:9865
Change-Id: I6a67779dc99fdc1c6bda6a2526d0e9ee5385f3ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924442
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65098}
This is an unmodified reland of 3c98a2a36a.
The actual issue was fixed in https://crrev.com/c/1926769.
Original change's description:
> [wasm] Prevent breakpoints on nonbreakable positions
>
> If a breakpoint is set on a non-breakable position, the wasm interpreter
> just stores the value 0xFF (kInternalBreakpoint) in the function body
> (actually, a copy of the function body). This might overwrite immediates
> and cause subsequent failures in the wasm interpreter.
>
> In JavaScript, breakpoints are just forwarded to the next breakable
> position. This CL implements the same for WebAssembly.
> A cctest tests this behavior, and the existing
> wasm-stepping-byte-offsets.js inspector test is extended to also set the
> breakpoint within an i32 constant immediate.
>
> R=leese@chromium.org, mstarzinger@chromium.org
> CC=bmeurer@chromium.org
>
> Bug: chromium:1025184
> Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65070}
Bug: chromium:1025184
Change-Id: I5e16df645bbacf039b7a5e55a0c2a64cdb4c6a32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926152
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65093}
Also some cleanup reordering of instruction codes.
Bug: v8:9813
Change-Id: I35caad0b84dd5824090046cba964454eac45d5d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925613
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65088}
This change defines a way that v8_debug_helper can describe object
fields which are packed structs, and uses it for the "descriptors" field
in DescriptorArray.
In more detail:
- debug-helper.h (the public interface for v8_debug_helper) adds a size
and an optional list of struct properties to ObjectProperty.
- debug-helper-internal.h mirrors those changes to the internal class
hierarchy which maintains proper unique_ptr ownership.
- In src/torque/class-debug-reader-generator.cc,
- Some existing logic is moved into smaller functions.
- New logic is added to generate the field list for structs. Example
output is included in a comment above the function
GenerateGetPropsChunkForField.
Bug: v8:9376
Change-Id: I531acac039ccb42050641448a4cbaec26186a7bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1894362
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65079}
This reverts commit 3c98a2a36a.
Reason for revert: Fails on arm: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/12134
Original change's description:
> [wasm] Prevent breakpoints on nonbreakable positions
>
> If a breakpoint is set on a non-breakable position, the wasm interpreter
> just stores the value 0xFF (kInternalBreakpoint) in the function body
> (actually, a copy of the function body). This might overwrite immediates
> and cause subsequent failures in the wasm interpreter.
>
> In JavaScript, breakpoints are just forwarded to the next breakable
> position. This CL implements the same for WebAssembly.
> A cctest tests this behavior, and the existing
> wasm-stepping-byte-offsets.js inspector test is extended to also set the
> breakpoint within an i32 constant immediate.
>
> R=leese@chromium.org, mstarzinger@chromium.org
> CC=bmeurer@chromium.org
>
> Bug: chromium:1025184
> Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65070}
TBR=mstarzinger@chromium.org,clemensb@chromium.org,bmeurer@chromium.org,leese@chromium.org
Change-Id: I7468ea3b15fecccdea521308325cf4851e0a0396
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1025184
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926032
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65074}
This is necessary because the spec changed.
R=mstarzinger@chromium.org
Bug: v8:9865
Change-Id: Id8b4d85eafcf368d591666907036e6aa54664e63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921794
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65072}
If a breakpoint is set on a non-breakable position, the wasm interpreter
just stores the value 0xFF (kInternalBreakpoint) in the function body
(actually, a copy of the function body). This might overwrite immediates
and cause subsequent failures in the wasm interpreter.
In JavaScript, breakpoints are just forwarded to the next breakable
position. This CL implements the same for WebAssembly.
A cctest tests this behavior, and the existing
wasm-stepping-byte-offsets.js inspector test is extended to also set the
breakpoint within an i32 constant immediate.
R=leese@chromium.org, mstarzinger@chromium.org
CC=bmeurer@chromium.org
Bug: chromium:1025184
Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65070}
These instructions should always treat inputs as signed, and saturate to
unsigned min/max values.
E.g. given -1, it should saturate to 0.
The spec text,
https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md#integer-to-integer-narrowing,
has been updated to describe this.
The changes here include codegen changes to ia32, x64, arm, and arm64,
changes to arm simulator, assembler, and disassembler to handle the case
of treating input as signed and narrowing to unsigned. The vqmovn
instruction can handle this case, our assembler wasn't allowing callers
to specify this.
The interpreter and scalar lowering are also fixed with this change.
Bug: v8:9729
Change-Id: I6f72baa825f59037f7754485df6a2964af59fe31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879423
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65051}
For arm64 decompressing a TaggedSigned results in a 64-bit value, with
the top 32 bits zeroed and the lower 32 bits being the SMI. This patch,
with the --debug-code flag enabled, will corrupt the top 32 bits to try
and catch places that are using 64-bit operations instead of 32-bit operations.
Change-Id: I3d3048c4f4b87f3bce26d0c7eb41789ec6b99f5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917099
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Joey Gouly <joey.gouly@arm.com>
Cr-Commit-Position: refs/heads/master@{#65035}
Individual frames of a stack frame in the frame cache might point
to the JSFunction of that corresponding stack frame. It is illegal to
serialize JSFunction objects in the isolate snapshot, so the attempt
to serialize the stack frame cache results in a crash. This can happen
when a warmup script is run, before a snapshot is created.
This CL fixes the crash by not utilizing the stack frame cache in case
the serializer is enabled.
Change-Id: I8b79a06b8cff36e1f54b54d3d8e5397b07ba52e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1923068
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65026}
This implements the rest of the load extend instructions:
- i32x4.load16x4_s
- i32x4.load16x4_u
- i64x2.load32x2_s
- i64x2.load32x2_u
Bug: v8:9886
Change-Id: I4649f77bae5224042a1628d9f0498c050b1e599d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903812
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65017}
For many subclasses of JSObject, we used kSize instead of kHeaderSize
even though they can contain in-object properties. In fact, kSize
was very much used as the header size, as can be seen in many examples
in this CL.
This change is a preparation for a for a cleanup of how Torque
generates field offsets.
TBR=hpayer@chromium.org
Change-Id: I350e996057cd66c427381334080f8ac93de88597
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917141
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65013}
This makes sure that the {WasmGraphBuilder} properly detects the
presence of Simd128 global.get and global.set opcodes and triggers
scalar lowering on architectures without Simd128 support.
R=clemensb@chromium.org
TEST=cctest/test-run-wasm-simd/RunWasm_S128Globals
BUG=v8:9973
Change-Id: I1538bd1d3fea40cc78e82b125d4f113842faf68a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917148
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65002}
utils.h itself is fairly large and contains lots of unrelated functions
as well as having a fair number of dependencies itself, so this splits
bounds checking and bit field operations into their own headers in base
and replaces uses of utils.h with the more appropriate header where
possible. (Also fixes some cases where other headers were previously
brought in transitively).
Bug: v8:9810, v8:8912
Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604
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@{#64983}
In Liftoff, we have a good estimate about how big the generated code
might get. Also, we often compile hundreds of functions which each hold
an assembler buffer alive until we finally add that code to the wasm
module.
In order to reduce memory consumption in Liftoff, this CL reduces
{AssemblerBase::kMinimalBufferSize} from 4096 to 128, and adds
{AssemblerBase::kDefaultBufferSize} to be used instead.
R=jkummerow@chromium.org
Change-Id: I7029bf501244770f4824a86b233d7f99c4b7910b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914559
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64958}
This removes {CPURegister::Is} and {CPURegister::is}, and just uses
{CPURegister::operator==} instead.
Drive-by: Use DCHECK_EQ and DCHECK_NE where possible.
R=mstarzinger@chromium.org
Bug: v8:9810
Change-Id: I03aad8b4223bd4ae37d468326a734f7a5c3c8061
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916202
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64956}
Just use the default {is_valid} method provided by RegisterBase.
Drive-by: Also rename {CPURegList::IsValid} to {CPURegList::is_valid}.
R=mstarzinger@chromium.org
Bug: v8:9810
Change-Id: Ia3bc3c477e6329d63ffd00bca59762d9a6cf2fcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916201
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64952}
This reverts commit d46bd852ad.
Reason for revert: I suspect this breaks the 'V8 Linux - predictable' bot. Specifically, 'typedarray-copywithin' has been failing since this landed. I am not exactly sure what is wrong from the tests error message, but see this link for more information:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8896980452133814304/+/steps/Check_-_d8__flakes_/0/logs/typedarray-copywithin/0
Original change's description:
> [ic] Migrate Code-based handlers to use data driven handler.
>
> All usage of KeyedLoadIC_Slow, HasIC_Slow, StoreInArrayLiteralIC_Slow
> and KeyedStoreIC_Slow now use data driven handlers
>
> Bug: v8:9779
> Change-Id: Idd888c5c10b462a5fe155ba0add36f95169bd76d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895988
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Suraj Sharma <surshar@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#64918}
TBR=rmcilroy@chromium.org,verwaest@chromium.org,surshar@microsoft.com
Change-Id: Id7c2b553f85b46048bed2c633b8bd24098f67147
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9779
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1912092
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64922}
All usage of KeyedLoadIC_Slow, HasIC_Slow, StoreInArrayLiteralIC_Slow
and KeyedStoreIC_Slow now use data driven handlers
Bug: v8:9779
Change-Id: Idd888c5c10b462a5fe155ba0add36f95169bd76d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895988
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Suraj Sharma <surshar@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#64918}
UMA data shows that we currently still allocate up to ten code spaces
per module. This is because the code size estimates are vastly off,
especially if both Liftoff and TurboFan is being used.
Also, code sizes differ by platform.
This CL adds more logic to the {EstimateNativeModuleCodeSize} function
to distinguish Liftoff and TurboFan, and to use different constants per
platform. A largeish comment explains how the numbers were generated,
and that they are an extreme over-generalization. However, without
further information about the module, this is the best we can do.
After all, being off even by a factor of two does not hurt too much, as
explained in the comment.
R=jkummerow@chromium.org
Change-Id: Icd178f5f4d0c7c8fa29b11b6eff7d14e64a1af1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910102
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64913}
This patch excludes brand symbols from the result of
JSReceiver::GetPrivateEntries so that the brands do not show up
when the instances are inspected from the DevTools (e.g. via
`Runtime.getProperties()`).
To implement this, we use a bit in the Symbols to denote whether
it's a brand symbol. A brand symbol is also a private name
symbol so that we can just reuse the IC for accessing private
names and do not need to jump through extra ORs.
Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
Bug: v8:8671, v8:9839, v8:8330
Change-Id: I24346aeedce3602395289052d1e1350ae9390354
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1909757
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#64899}
Instead of changing all of TryToName to do the conversion to array
index, this patch narrows this fast path just to the element load IC
handler.
This patch also restores the HeapNumber conversion in TryToIntPtr and
in Turbofan inlining as per the original state of things.
Bug: v8:9449, chromium:1016738, chromium:1016709
Change-Id: Ibf3a2c38637fc36e0ee037dc740f273848d1e8a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1902386
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64896}
The function-entry stack check should dominate all other
instructions in a function. Prior to this CL it was possible to create
paths not including a stack check due to SwitchOnGeneratorState: the
generator-creation branch had a stack check, while generator-resume
branches did not.
0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 }
4 : 27 fe fa Mov <closure>, r1
7 : 27 02 f9 Mov <this>, r2
10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2
14 : 26 fb Star r0
16 : a7 StackCheck
17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0]
22 : b1 fb fb 01 ResumeGenerator r0, r0-r0
[... no stack check here ...]
This CL moves the stack check to the beginning of the bytecode array,
i.e. before SwitchOnGeneratorState.
Bug: chromium:1020031
Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64888}
Including but not limiting to removing:
* BitcastCompressedXXX
* CheckedCompressedXXX
* ChangeXXXToCompressedYYY
* ChangeCompressedXXX
As a note, ChangeTaggedToCompressed can't be removed just yet as it
is still in use.
Bug: v8:7703
Change-Id: I98cf88a32adfa976d419e69702d1cac4d3e811a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903435
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64880}
This makes the {code_size_estimate} computation explicit in the caller,
and removes one of the two {NewNativeModule} constructors. It turns out
that the calculation is totally off in the streaming calculation phase,
since no function bodies have been parsed yet. So all
{WasmFunction::code} fields are still empty, and we compute an estimate
that is way too low.
This CL prepares the actual fix for that (by computing a better estimate
at specific call sites).
R=ahaas@chromium.org
Bug: v8:9950
Change-Id: I68a891c97e5f65a9c7e73e21684bdfa7e261e216
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1901273
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64845}
Introduce new operator LoadTransform that holds a LoadTransformInfo param,
which describes the kind of load (normal, unaligned, protected), and a
transformation (splat or extend, signed or unsigned).
We have a new method that a full decoder needs to implement, LoadTransform,
which resuses the existing LoadType we have, but also takes a LoadTransform,
to distinguish between splats and extends at the decoder level.
This implements 4 out of the 10 suggested load splat/extend operations
(to keep the cl smaller), and is also missing interpreter support (will
be added in the future).
Change-Id: I1e65c693bfbe30e2a511c81b5a32e06aacbddc19
Bug: v8:9886
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863863
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64819}
