This allows to hold a constexpr (empty) "builder" object instead of
creating it for every use.

R=ahaas@chromium.org

Bug: v8:11384
Change-Id: Ib5e13c58e81a950bb5dd0e8eefe4021bc77d8b64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773801
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73548}

The initial implementation of {FixedSizeSignature} contains undefined
behaviour, because {InitReps} wrote to the {reps_} array before the
constructor of that array has been called.
This also resulted in bugs if {FixedSizeSignature} was used with types
that actually have a constructor (like {ValueType}). The array
constructor would call the default constructor on each contained
element, thus overwriting the values written by {InitReps}.

This CL fixes that by switching to a plain array, and only writing to
the array in the body of the constructor (after the field was properly
initialized).

It also removes the {Concat} method in favor or simply copying from two
input arrays in a private constructor.

Drive-by: Use proper constant names for the template parameters to
make cpplint happy.

R=ahaas@chromium.org

Bug: v8:11384
Change-Id: Id748c8fef3c846069f91843f74d0555ed8ca9fb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773799Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73540}

Liftoff defines many signatures of fixed size. This is currently done by
defining a fixed-size array on the stack, and then using this in the
signature definition. This is cumbersome and hard to read, since the
array contains return types and parameter types, and only the signature
definition separates the two. But also the order of those two sizes in
the signature is non-obvious and easy to get wrong.

This CL introduces a helper to define fixed-size signatures in a
"builder style", i.e. parameters and return types can be added
separately. The fixed-size array will be contained in the returned
class, so it will still be stack-allocated like before. The copies to
iteratively build up this array should be completely eliminated by the
compiler, so the binary code should look exactly the same.

R=ahaas@chromium.org

Bug: v8:11384
Change-Id: I167830d6c3429f535b7d1241920730498a9bb4c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2747505
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73341}

Use a Foreign pointer for the signature in the generic JS-to-Wasm wrapper.

Bug: v8:10701
Change-Id: I30d5894e8b8a48c258b7a6e003813c8403c1075e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2369178Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69580}

... by migrating old-style code
  MyObject* obj = new (zone) MyObject(...)

to the new style
  MyObject* obj = zone->New<MyObject>(...)

Bug: v8:10689
Change-Id: Iea6c1225ee672035763d8141292a40874658d270
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288864
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68788}

This replaces all typedefs that define types and not functions by the
equivalent "using" declaration.

This was done mostly automatically using this command:
ag -l '\btypedef\b' src test | xargs -L1 \
     perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'

Patchset 2 then adds some manual changes for typedefs for pointer types,
where the regular expression did not match.

R=mstarzinger@chromium.org
TBR=yangguo@chromium.org, jarin@chromium.org

Bug: v8:9183
Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61849}

Bug: v8:9247

TBR=bmeurer@chromium.org,neis@chromium.org
NOPRESUBMIT=true

Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61682}

To allow any-ref parameters, we have to make sure that any-ref stack
parameters get seen by the GC. This CL is a first step into that
direction. The goal of this CL is to group any-ref parameters at the
stack side of the parameters. This means that in the stack frame
iterator we do not need information about where anyref parameters are
in the stack frame. We only need information about how many anyref
parameters there are at the bottom of the stack frame.


R=mstarzinger@chromium.org

Also-By: mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I3ff7cc38fabed5f8e51b5b990190e35f3ea29803
Reviewed-on: https://chromium-review.googlesource.com/c/1371827
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58184}

Replaces some DCHECK with their verbose equivalent because it's more
convenient while debugging.

Change-Id: I83c199c389341a68dfccd949e7353ef68ff3b9c2
Reviewed-on: https://chromium-review.googlesource.com/c/1352289Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58013}

An unordered_map typically provides better performance. Instead of a
compare function, we now need a hash function and equality defined on
{Signature<T>}.

R=mstarzinger@chromium.org

Bug: chromium:862123
Change-Id: Iba71030f91949d7453740c884de1d8a4f921c618
Reviewed-on: https://chromium-review.googlesource.com/1131182
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54404}

Restores some sensemaking properties, such as making src/machine-type.h (lower
level header) independent of src/zone/zone.h (higher level header).

BUG=v8:7490

Change-Id: Ibc6e5c7a75e4aaf917d086cf70267abc7ee9a9b0
Reviewed-on: https://chromium-review.googlesource.com/1039586Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52941}

Both lazy initialization and static initialization (via static
initializer) are bad. Fortunately, the arrays we are constructing are
constant anyway, so we can just compute them at compile time. This is
enforced by making them constexpr.
This also saves all code needed for the initialization, and makes
accesses to the tables faster, as they don't need any atomic operations
(via LazyInstance).

R=ahaas@chromium.org

Change-Id: I7d3ba9b0f2602f596a6c71c8c567e0d1bc306268
Reviewed-on: https://chromium-review.googlesource.com/517083
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45589}

This introduces iterators for the parameters and return types of a
signature. This required extending the constructor of iterator_range
for perfect forwarding.

I also moved the HasJSCompatibleSignature to a header file in order to
reuse it from the interpreter.

R=ahaas@chromium.org, titzer@chromium.org

Change-Id: Ie77f87ef87fdfd3138b2106640ac7c481cf247e6
Reviewed-on: https://chromium-review.googlesource.com/455777
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43854}

The generated code for JSToWasm wrappers only depends on the signature
of the exported function. Hence, we can reuse the generated code and
just patch the reference to the called wasm code.

For the unity-wasm benchmark, we reach a hit rate of 98.07% for this
cache, and only 395 instead of 20471 wrappers are compiled. This brings
down instantiation time from 2.9s to 1.6s on a MBP.

R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2705993002
Cr-Commit-Position: refs/heads/master@{#43322}

This CL refactors the handling of metadata associated with WebAssembly
modules to reduce the duplicate marshalling of data from the C++ world
to the JavaScript world. It does this by wrapping the C++ WasmModule*
object in a Foreign that is rooted from the on-heap WasmCompiledModule
(which is itself just a FixedArray). Upon serialization, the C++ object
is ignored and the original WASM wire bytes are serialized. Upon
deserialization, the C++ object is reconstituted by reparsing the bytes.

This is motivated by increasing complications in implementing the JS
API, in particular WebAssembly.Table, which must perform signature
canonicalization across instances.

Additionally, this CL implements the proper base + offset initialization
behavior for tables.

R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
BUG=v8:5507, chromium:575167, chromium:657316

Review-Url: https://chromiumcodereview.appspot.com/2424623002
Cr-Commit-Position: refs/heads/master@{#40434}

This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.

BUG=v8:5409

Review-Url: https://codereview.chromium.org/2344143003
Cr-Commit-Position: refs/heads/master@{#39558}

This reverts commit 1eb1dfab.

The original compilation separation change avoided associating a heap
for the wasm instance if memory was not provided, nor needed. The
grow memory CL assumed the old behavior, where a memory buffer was
always present, but may have had a zero size.

The 2CLS  landed shortly after one another. We decided to treat the
grow memory as the race condition winner, so this CL here re-lands
compilation separation, plus adjusts grow memory to deal with
the undefined mem buffer.

BUG=

Review-Url: https://codereview.chromium.org/2102193003
Cr-Commit-Position: refs/heads/master@{#37352}

This reverts commit 0c7ee927.

BUG=

Review-Url: https://codereview.chromium.org/2103983003
Cr-Commit-Position: refs/heads/master@{#37351}

Support for serializing/deserializing the compiled wasm module.

We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.

We currently hold on to the un-decoded wasm bytes, for enabling
debugging scenarios. This imposes a ~20% penalty on the memory
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information
necessary to support instantiation.

Given how whatever we need to persist must be serializable, the CL
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer.

Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.

This CL also moves export compilation ahead of instantiation time.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

BUG=

Review-Url: https://codereview.chromium.org/2094563002
Cr-Commit-Position: refs/heads/master@{#37348}

R=bmeurer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1118823003

Cr-Commit-Position: refs/heads/master@{#28191}